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Indian Standard 

INFORMATION TECHNOLOGY — 

TELECOMMUNICATIONS AND INFORMATION 

EXCHANGE BETWEEN SYSTEMS — OPEN SYSTEMS 

INTERCONNECTION — PROTOCOL FOR PROVIDING 

THE CONNECTION — MODE TRANSPORT SERVICE 



NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 8073:1992 'Information technology — Teleconnmunications and 
information exchagne between systems — Open systems interconnection — Protocol for providing the connection 
— mode transport sevice', issued by the International Organization for Standardization (ISO) was adopted by the 
Bureau of Indian Standards on the recommenation of Computer Systems and Interconnection Sectional Committee 
(LTD 36) and approval of the Electronics and Telecommunication Division Council. 

In the adopted standard certain terminology and conventions are however not identical to those used in Indian 
Standards. Attention is particularly drawn to the following: 

Where the words 'International Standard' appear referring to this standard, they should be read as 'Indian Standard*. 

In this Indian Standard, the following Inlernationai Standards are referred to. Read in their respective place the 
following: 



International 
Standard 

ISO 7498 : 1 984 Information process- 
ing system — Open systems intercon- 
nection — Basic reference model 



ISO 7498-3 : 1 989 Information process- 
ing systems — Open systems intercon- 
nection — Basic reference model — 
Part 3: Naming and addressing 

ISO 8072 : 1986 Information process- 
ing systems— Open systems intercon- 
nection — Transport service definition 

ISO/IEG 8348:1992 Information pro- 
cessing systems — Data communica- 
tions — Network service definition 



Corresponding Indian Standard 



IS 12373 {Part 1) ; 1987 Basic refer- 
ence model of open systems intercon- 
nection forinformation processing sys- 
tems: Part 1 

IS 1 2373 (Part 3) ; 1 992 Basic reference 
model of open systems interconnection 
processing systems : Part 3 Naming 
and addressing 

IS 13589:1993 Transport service defi- 
nition in open systems interconnection 
for information processing systems 

IS 13868 : 1 994 Network service defi- 
nition in data communication for infor- 
mation processing systems 



Degree of 
Equivalence 

Identical 



Identical 



Identical 



Identical 



The technicalcommitteeresponsibleforthe preparation of this standard has reviewedthe provisions of the following 
ISO Standards and has decided that they are acceptable for use in conjunction with this standard: 

ISO/IEC 11570:1992 Information technoiogy — Telecommunications and information exchange between 
systems — Open systems interconnection — Transport protocol identification mechanism. 

CCITT X. 224 Transport protocol specification for open systems interconnections for CCITT Applications, 
version 1988. 
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1 Scope 

This International Standard specifies 

a) five classes of procedures wlien operating over the 
connection-mode network service; 

1 ) class 0; simple class; 

2) class 1 : basic error recovery class; 

3) class 2: multiplexing class; 

4) class 3: error recovery and multiplexing class; 

5) class 4: error detection and recovery class; 

for the connection-mode transfer of data and control 
information from one transport entity to a peer transport 
entity; 

b) one class (class 4) of procedure when operating over 
the connectionless-mode network service; 

c) the means of negotiating the class of procedures to 
be used by the transport entities; 

d) the structure and encoding of the transport protocol 
data units used for the transfer of data and control 
information. 



These procedures are applicable to instances of 
communication between systems which support the 
Transport Layer of the OSI Reference Model and which 
wish to interconnect in an open systems environment. 

This International Standard specifies, in clause 14, 
conformance requirements for systems implementing these 
procedures and provides the PICS proforma in compliance 
with the relevanr requirements, and in accordance with the 
relevant guidance, given in ISO/IEC 9646-2. It does not 
contain tests which can be used to demonstrate this 
conformance. 



2 Normative references 

The following standards contain provisions which, through 
reference in this text, constitute provisions of this 
International Standard. At the time of publication, the 
editions indicated were valid. All standards are subject to 
revision, and parties to agreements based on this 
International Standard are encouraged to investigate the 
possibility of applying the most recent editions of the 
standards listed below. Members of I EC and ISO maintain 
registers of currently valid International Standards. 

ISO 7498:1984, Information processing systems — Open 
Systems Interconnection — Basic Reference Model. 



The procedures are defined in terms of 

a) the interactions between peer transport entities 
through the exchange of transport protocol data units; 

b) the interactions between a transport entity and the 
transport service user in the same system through the 
exchange of transport service primitives; 

c) the interactions between a transport entity and the 
network service provider through the exchange of 
network service primitives. 

These procedures are defined in the main text of this 
International Standard supplemented by state tables in 
annex A. 



ISO 7498:1984/Add. 1:1987, Information processing 
systems - Open Systems Interconnection - Basic 
Reference l\Aodel - Addendum 1: Connectionless-mode 
transmission. 

ISO 7498-3:1989, Information processing systems - Open 
Systems Interconnection - Basic Preference Model ~ Part 3: 
Naming and addressing. 

ISO 8072:1986, Information processing systems — Open 
Systems Interconnection — Transport service definition. 

ISO/IEC 8348:1992, Information processing systems — 
Data communications — Network service definition. 
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ISO/iEC 9646-1:1991, Information technology - Open 
Systems Interconnection - Conformance testing 
methodology and framework - Part 1: General concepts. 

ISO/IEC 9646-2:1991, Information technology - Open 
Systems Interconnection - Conformance testing 
methodology and framework - Part 2: Abstract test suite 
specification. 



ISO/IEC 11570:1992, Information technology — 
Telecommunications and information exchange between 
systems — Open Systems Interconnection — Transport 
protocol identification mechanism. 

CCITT X.224, Transport Protocol Specification for Open 
Systems Interconnection for CCITT Applications Version 
1988. 
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Section one: General 



3 Definitions 

NOTE - The definitions contained in this clause make use of 
abbreviations defined in clause 4. 

3.1 This International Standard is based on the concepts 
developed in ISO 7498 and ISO 7498/Add.1 and tSO/lEC 
7498-3 and makes use of the following terms defined in it: 

a) concatenation and separation; 

b) segmenting and reassembling; 

c) multiplexing and demultiplexing; 

d) splitting and recombining; 

e) flow control; 

f) connectionless-mode transmission; 

g) nil selector value. 

3.2 For the purposes of this International Standard, the 
following definitions apply: 



3.2.8 receiving transport entity: 

that receives a given TPDU. 



A transport entity 



3.2.9 preferred class: The protocol class that the 
initiator indicates in a CR T-PDU as its first choice for use 
over the transport connection. 

3.2.10 alternative class: A protocol class that the 
initiator indicates in a CR TPDU as an alternative choice for 
use over the transport connection. 



3.2.11 proposed class: 

alternative class. 



A preferred class or an 



3.2.12 selected class: The protocol class that the 
responder indicates in a CC TPDU that it has chosen for 
use over the transport connection. 

3.2.13 proposed parameter: The value for a parameter 
that the initiator indicates in a CR TPDU that it wishes to 
use over the transport connection. 

3.2.14 selected parameter: The value for a parameter 
that the responder indicates in a CC TPDU that it has 
chosen for use over the transport connection. 



3.2.1 equipment: Hardware or software or a 
combination of both; it need not be physically distinct within 
a computer system. 

3.2.2 transport service user: An abstract 
representation of the totality of those entities within a single 
system that make use of the transport service. 

3.2.3 networi< service provider: An abstract machine 
that models the totality of the entities providing the network 
service, as viewed by a transport entity. 



3.2.15 error indication: An N-RESET indication, or an 
N-DISCONNECT indication with a reason code indicating 
an error, that a transport entity receives from the NS- 
provider. 

3.2.16 invalid TPDU: A TPDU that does not comply 
with the requirements of this International Standard for 

structure and encoding. 

3.2.17 protocol error: A TPDU whose use does not 
comply with the procedures for the class. 



3.2.4 local matter: A decision made by a system 
concerning its behavior in the Transport Layer that is not 
subject to the requirements of this protocol. 

3.2.5 initiator: A transport entity that initiates a CR 
TPDU. 

3.2.6 responder: A transport entity with whom an 
initiator wishes to establish a transport connection. 

NOTE - Initiator and responder are defined with respect to a single 
transport connection. A transport entity can be both an initiator and 
responder simultaneously, 

3.2.7 sending transport entity: A transport entity that 
sends a given TPDU. 



3.2.18 sequence number: 

a) the numt - r In tlie TPDU NR field of a DT TPDU that 
indicates the o-der in which the DT TPDU was 
transmitted '>y a transport entity; 

b) the number in the YR-TU-NR field of an AK or RJ 
TPDU that indicates the sequence number of the next 
DT TPDU expected to be received by a transport entity. 

3.2.19 transmit window: The set of consecutive 
sequence numbers which a transport entity has been 
authorized by its peer entity to send at a given time on a 
given transport connection. 
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3.2.20 lower window edge: 

number in a transmit window. 



The lowest sequence 4 Symbols and abbreviations 



3.2.21 upper window edge: The sequence number 
which is one greater that the highest sequence number in 
the transmit window. 

3.2.22 upper window edge allocated to the peer 
entity: The value that a transport entity communicates to 
its peer entity to be interpreted as its new upper window 
edge. 

3.2.23 closed window: A transmit window that contains 
no sequence number. 

3.2.24 window information: Information contained in a 
TPDU relating to the upper and the lower window edges. 

3.2.25 frozen reference: A reference that is not 
availabJG for assignment to a connection because of the 
requirements of 6.18. 

3.2.26 unassigned reference; A reference tKat is 
neither currently in use for identifying a transport connection 
nor which is in a frozen state. 

3.2.27 transparent (data): TS-user data that is 
transferred intact between transport -entities and which is 
unavailable for use by the transport entities. 

3.2.28 owner (of a netv/ork connection): The transport 
entiry that issued the N-CONNECT request leading to the 
creation of that network connection. Only applicable when 
operating over the connection-mode network service. 

3.2.29 retained TPDU: A TPDU that is subject to the 
retransmission procedure or retention and 
acknowledgement procedure and is available for possible 
retransmission. 



3.3 This International Standard uses the following terms 
defined in iSO/lEC 8348: 

a) connection-mode network service 

b) connectionless-mode network service 

3.4 This International Standard uses the following terms 
defined in ISO/lEC 9646-1 : 

a) PICS proforma 

b) protocol implementation conformance statement 
(PICS) 



4.1 Data units 

TPDU Transport-protocol-data-unit 
TSDU Transport-service-data-unit 
NSDU Network-service-data-unit 

4.2 Types of Transport Protocol data units 

CR TPDU Connection request TPDU 

CC TPDU Connection confirm TPDU 

DR TPDU Disconnect request TPDU 

DC TPDU Disconnect confirm TPDU 

DT TPDU Data TPDU 

ED TPDU Expedited data TPDU 

AK TPDU Data acknowledge TPDU 

EA TPDU Expedited acknowledge TPDU 

RJ TPDU Reject TPDU 

ERTPDU Error TPDU 

4.3 TPDU Fields 



LS 


Length indicator (field) 


CDT 


Credit (field) 


TSAP-ID 


Transport-service-access-point identifier 




(field) 


DST-REF 


Destination reference (field) 


SRC-REF 


Source reference (field) 


EOT 


End of TSDU mark 


TPDU-NR 


DT TPDU number (field) 


ED-TPDU-NR 


ED TPDU number (field) 


YR-TU-NR 


Sequence number response (field) 


YR-EDTU-NR 


ED TPDU number response (field) 


ROA 


Request of acknowledgement mark 



4.4 Times and associated variables 

77 Local retransmission time 

N The maximum number of transmissions 

L Time bound on reference and sequence number 

/ Inactivity time 

W Window time 

TTR Time to try reassignment/resynchronization 

TWR Time to wait for reassignment/resynchronization 

TS1 Supervisory timer 1 

TS2 Supen/isory timer 2 

Mi^pi NSDU lifetime local-to-remote 

Mpfi^ NSDU lifetime remote-to-local 

EiFi Expected maximum transit delay local-to-remote 

Epii Expected maximum transit delay re mote-to- local 

R Persistence time 

Ai^ Local acknowledgement time 

Apj Remote acknowledgement time 

/^ Local inactivity time 

Ipj Remote inactivity time 
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4.5 Miscellaneous 

TS-user Transport-service user 

TSAP Transport-service-access-point 

NS-provider Network service provider 

NSAP Network-service-access-point 

QOS Quality of service 

CLNS Connectionless-nnode network service 

CONS Connection-mode network service 



5 Overview of the Transport Protocol 

NOTE - This ov9n/iew is not exhaustive and has been provided for 
guidance. 

5.1 Service provided by the Transport Layer 

The protocol specified in this International Standard 
supports the Transport Sen/ice defined in ISO 8072. 

Infornnation is transferred to and from the TS-user in the 
transport service primitives listed in Table 1. 



5.2 Service Assunmed from the Network Layer 

The protocol specified in this International Standard 
assumes the use of the Network Service defined in ISO/IEC 
8348. 

When operating over CONS, information is transferred to 
and from the NS-provider in the network service primitives 
listed in Table 2a). When operating over CLNS, information 
is transferred to and from the NS-provider in the network 
service primitives listed in table 2b). 

NOTES 

1 The parameters listed in Table 2a) are those in the current 
connection-mode network service (see ISO/IEC 8348). 

2 The parameters listed in table 2b) are those in the current 
connectionless-mode networi< service (see ISO/IEC 8348). 

3 The way the parameters are exchanged between the transport 
entity and the NS-provider is a local matter. 





Table 1 - Transport service primitives 


Primitives 


Parameters 


T-CONNECT 


request 
indication 


Called address 
Calling address 
Expedited data option 
Quality of service 
TS-user data 


T-CONNECT 


response 
confirm 


Responding address 
Quality of service 
Expedited data option 
TS-user-data 


T-DATA 


request 
indication 


TS-user-data 


T-EXPEDITED DATA request 
indication 


TS-user-data 


T-DISCONNECT 


request 


TS-user-data 


T-DISCONNECT 


indfcation 


Disconnect reason 
TS-user-data 
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Table 2a) - Connection-mode network service primitives 



Primitives 


X/Y 


Parameters 


W/X/Y/Z 


N-CONNECT 


request 
indication 


X 
X 


Called address 
Calling address 

Receipt confirmation selection 
Expedited data selection 
QOS parameter set 
NS-user-data 


X 
X 

Y 
Y 
X 

Z 


N-CONNECT 


response 
confirm 


X 
X 


Responding address 
Receipt confirmation selection 

Expedited data selection 
QOS parameter set 
JMS-user-data 


X 
Y 

Y 
X 

Z 


N-DATA 


request 
indication 


X 
X 


N- user-data 
Confirmation request 


X 

Y 


N-DATA ACKNOWLEDGE 


request 
indication 


Y 
Y 




N-EXPEDITED DATA 


request 
indication 


Y 
Y 


NS-user-data 


Y 


N-RESET 


request 
indication 


X 
X 


Reason 

Originator 

Reason 


W 
W 
W 


N-RESET 


response 
confirm 


X 
X 


— 


N-DtSCONNECT 


request 
indication 


X 
X 


Reason 
NS-user-data 
Responding address 

Originator 
Reason 
NS-user-data 
Responding address 


W 
Z 

z 

w 
w 

z 
z 



Key: 
W: 
X: 
Y: 



The usage of this parameter Is a loc^l matter, e.g. for diagnostic or to decide whether to attempt resynchronization. 

The Transport Protocol assumes that this facility is provided in all networks. 

The Transport Protocol assumes that this facility is provided in some networks and a mechanism is provided to 

optionally use the facility. 

The Transport Protocol does not use this parameter. 





Table 2b) - Connectionless- 


mode network service primitives 




Primitives 


X/Y 


Parameters 


W/X/Y/Z 


N-UNITDATA 


request 
indication 


X 
X 


Source address 
Destination address 
Quality of service 
NS-user-data 

Source address 
Destination address 
Quality of service 

NS-user-data 


X 
X 
X 
X 

X 
X 
X 
X 



Key: 
W: 
X: 
Y: 



The usage of this parameter Is a local matter, e.g. for diagnostic or to decide whether to attempt resynchronization. 

The Transport Protocol assumes that this facility is provided in all networks. 

The Transport Protocol assumes that this facility is provided in some networks and a mechanism is provided to 

optionally use the facility. 

The Transport Protocol does not use this parameter. 
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5.3 Functions of the Transport Layer 

5.3.1 Overview of functions 

The functions in the Transport Layer are those necessary to 
bridge the gap between the services available from the 
Network Layer and those to be ottered to the TS-users. 

The functions in the Transport Layer are concerned with the 
enhancement of quality of service, including aspects of cost 
optimization. 

These functions are grouped below into those used at all 
times during a transport connection and those concerned 
with connection establishment, data transfer and release. 

NOTE - This International Standard does not include the following 
functions which are under consideration for inclusion in future 
editions of this International Standard; 

a) encryption; 

b) accounting mechanisms; 

c) status exchanges and monitoring of QOS; 

d) blocking; 

e) temporary release of network connections; 

f) altemative checksum algorithm. 



5,3.1.1 



Functions used at all times 



The following functions, depending upon the selected class 
and options, are used at all times during a transport 
connection: 

a) transmission of TPDUs (6.2 and 6.9); 

b) multiplexing and demultiplexing (see 6.15): A 
function used only when operating over CONS to share 
a single network connection between two or more 
transport connections; 

c) error detections (see 6.10, 6.13 and 6.17): A 
function used to detect the loss, corruption, "duplication, 
misordering, or misdelivery of TPDUs; 

d) error recovery (see 6.12, 6.14, 6.18, 6.19, 6.20, 6.21, 
and 6.22): A function used to recover from detected and 
signalled errors. 



5.3.1.2 



Connection establishment 



The purpose of connection establishment is to establish a 
transport connection between two TS-users. The following 
functions of the transport layer during this phase match the 
TS-users' requested quality of service with the services 
ottered by the network layer: 



a) select the network service which best matches the 
requirement of the TS-user taking into account charges 
for various services (see 6.5); 

b) decide whether to multiplex multiple transport 
connections onto a single network connection only when 
operating over CONS (see 6.5); 

c) establish the optimum TPDU size (see 6.5); 

d) select the functions that will be operational upon 
entering the data transfer phase (see 6.5); 

e) map transport addresses onto network addresses; 

f) provide a means to distinguish between two different 
transport connections (see 6.5); 

g) transport of TS-user data (see 6.5); 

h) exchange values of Inactivity timers (see 6.5). 



5.3.1.3 



Data transfer 



The purpose of data transfer is to permit duplex 
transmission of TSDUs between the two TS-users 
connected by the transport connection. This purpose is 
achieved by means of two-way simultaneous 
communication and by the following functions, some of 
which are used or not used in accordance with the result of 
the selection performed in connection establishment. 

a) concatenation and separation (see 6.4): a function 
used to collect several TPDUs into a single NSDU at the 
sending transport entity and to separate the TPDUs at 
the receiving transport entity; 

b) segmenting and reassembling (see 6.3): a function 
used to segment a single data TSDU into multiple 
TPDUs at the sending transport entity and to 
reassemble them into their original format at the 
receiving transport entity; 

c) splitting and recombining (see 6.23): a function 
allowing, only when operating over CONS, the 
simultaneous use of two or more network connections to 
support the same transport connection; 

d) flow control (see 6.16): a function used to regulate 
the flow of TPDUs between two transport entities on one 
transport connection; 

e) transport connection identification: a means to 
uniquely identify a transport connection between the pair 
of transport entities supporting the connection during the 
lifetime of the transport connection; 

f ) expedited data (see 6.1 1 ): a function used to bypass 
the flow control of normal data TPDU. Expedited data 
TPDU flow is controlled by separate flow control; 
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g) TSDU delimiting (see 6.3): a function used to 
determine the beginning and ending of a TSDU. 

5,3.1.4 Release 

The purpose of release (see 6.7 and 6.8) is to provide 
disconnection of the transport connection, regardless of the 
current activity. 

5.4 Classes and options when operating over CONS 

5.4.1 General 

The functions of the Transport Layer have been organized 
into classes and options. 

A class defines a set of functions. Options define those 
functions within a class which may or may not be used. 

This International Standard defines five classes of protocol: 

a) class 0: simple class; 

b) class 1 : basic error recovery class; 

c) class 2: multiplexing class; 

d) class 3: error recovery and multiplexing class; 

e) class 4: error detection and recovery class. 
NOTES 

1 Transport connections of classes 2, 3 and 4 may be multiplexed 
together onto the same network connection. 

2 Classes to 3 do not specify mechanisms to detect unsignalled 
network transmission failures. 

5.4.2 Negotiation 

The use of classes and options is negotiated during 
connection establishment. The choice made by the 
transport entities will depend upon 

a) the TS-users' requirements expressed via T- 
CONNECT service primitives; 

b) the quality of the available network services; 

c) the user required service versus cost ratio 
acceptable to the TS-user. 

5.4.3 Choice of network connection 

The following list classifies network services in terms of 
quality with respect to error behavior in relation to user 
requirements; its main purpose is to provide a basis for the 
decision regarding which class of transport protocol should 
be used in conjunction with given network connection: 



a) Type A: Network connection with acceptable 
residual error rate (for example, not signalled by 
disconnect or reset) and acceptable rate of signalled 
errors. 

b) Type B: Network connections with acceptable 
residual error rate (for example, not signalled by 
disconnect or reset) but unacceptable rate of signalled 
errors. 

c) Type C: Network connections with unacceptable 
residual error rate. 

It is assumed that each transport entity is aware of the 
quality of service provided by particular network 
connections. 



5.4.4 Characteristics of class 

Class provides the simplest type of transport connection 
and is fully compatible with the CCITT Recommendation 
T. 70 for teletex terminals. 

Class has been designed to be used with type A network 
connections. 

5.4.5 Characteristics of class 1 

Class 1 provides a basic transport connection with minimal 
overheads. 

The main purpose of the class is to recover from network 
disconnect or reset. 

Selection of this class is usually based on reliability criteria. 
Class 1 has been designed to be used with type B network 
connections. 

5.4.6 Characteristics of class 2 

5.4.6.1 General 

Class 2 provides a way to multiplex several transport 
connections onto a single network connection. This class 
has been designed to be used with type A network 
connections. 

5.4.6.2 Use of explicit flow control 

The objective is to provide flow control to help avoid 
congestion at transport-connection-end-points and on the 
network connection. Typical use is when traffic is heavy 
and continuous, or when there is intensive multiplexing. 
Use of flow control can optimize response times and 
resource utilization, 

5.4.6.3 Non-use of explicit flow control 

The objective is to provide a basic transport connection with 
minimal overheads suitable when explicit disconnection of 
the transport connection is desirable. The option would 
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typically be used for unsophisticated terminals, and when no 
multiplexing onto network connections is required. 
Expedited data is never available. 



5.4.7 



Characteristics of class 3 



Class 3 provides the characteristics of class 2 plus the 
ability to recover from network disconnect or reset. 
Selection of this class is usually based upon reliability 
criteria. Class 3 has been designed to be used with type B 
network connections. 



5.4.8 



Characteristics of class 4 



Class 4 provides the characteristics of class 3, plus the 
capability to detect and recover from errors which occur as 
a result of the low grade of service available from the NS- 
provider. The kind of errors to be detected include: TPDU 
loss, TPDU delivery out of sequence, TPDU duplication and 
TPDU corruption. These errors may affect control TPDUs 
as well as data TPDUs. 

This class also provides for increased throughput capability 
and additional resilience against network failure. 

Class 4 has been designed to be used with type C network 

connections. 

5.5 Characteristics of class 4 transport protocol 
when operating over CLNS 

In operation over a connectioniess-mode network service 
the class 4 transport procotol provides flow control between 
communicating peer transport entities, the capability to 
detect and recover from errors which occur as a result of a 
low grade of service available from the NS-provider, and 
resilience from failure of the peer entity. The kinds of error 



to be detected include: TPDU loss, TPDU delivery out of 
sequence, TPDU duplication and TPDU corruption. These 
errors may affect control TPDUs as well as data TPDUs. 

NOTE - The transport entity is incapable of distinguishing between 
failure of the network sen/ice and failure of the peer entity, except 
optionally, by some local means, in the case of the failure of the 
local interface to the netwoik sen/ice (e.g., in the failure of the local 
transceiver on a local area network). 

There is no indication given to the transport entity about the 
ability of the network entity to fulfill the service requirements 
given in the N-UNITDATA primitive. However, it can be a 
local matter to make transport entities aware of the 
availability and characteristics (QO'S) of connectionless- 
mode network services, as the corresponding NSAP 
associations, exist logically by the nature of the 
connectionless-mode network service and may be 
recognized by network entities. 

5.6 (Model of the transport layer 

A transport entity communicates with its TS-users through 
one or more TSAPs by means of the service primitives as 
defined by the transport service definition (see ISO 8072). 
Service primitives will cause or be the result of transport 
protocol data unit exchanges between the peer transport 
entities supporting a transport connection. These protocol 
exchanges are effected using the services of the Network 
Layer as defined by the network service definition (see 
ISO/IEC 8348) through one or more NSAPs. 

Transport connection endpoints are identified in end 
systems by an internal, implementation dependent, 
mechanism so that the TS-user and the transport entity can 
refer to each transport connection. 





NOTE - For the purposes of illustration, figure 2 shows only one TSAR and one NSAP for each transport entity. In certain 
instances, more than one TSAP and/or more than one NSAP may be associated with a particular transport entity. 

Figure 2 - Model of the transport layer 
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Section two: Transport protocol specification 



6 Elements of procedure 

This clause contains elements of procedure whicli are used 
in tiie specification of protocol classes in clauses 7 to 12. 
These elements are not meaningful on their own. 

The procedures define the transfer of TPDUs whose 
structure and coding is specified in clause 13. Transport 
entities shall accept and respond to any TPDU received in a 
valid NSDU and may issue TPDUs initiating specific 
elements of procedure specified in this clause. 

NOTE - Whsre network service primitives, TPDUs and parameters 
used are not significant for a particular element of procedure, 
they have not been included in the specification. 

6.1 Use of the network service 

6.1.1 Assignment to networl< connection when 
operating over CONS 

This procedure is used only when operating over the 
connection-mode network service. 



6.1.1.1 



Purpose 



The procedure is used in all classes to assign transport 
connections to network connections. 



6.1 .1 .2 Network service primitives 

The procedure uses the following network service 
primitives: 



a) N-CONNECT; 

b) N-DISCONNECT. 



6.1.1.3 



Procedure 



Each transport connection shall be assigned to a network 
connection. The initiator may assign the transport 
connection to an existing network connection of which it is 
the owner or to a new network connection (see note 1) 
which it creates for this purpose. 

The initiator shall not assign or reassign the transport 
connection to an existing network connection if the protocol 
class{es) proposed for the class in use for the transport 
connectiorS- are incompatible with the current usage of the 
network connection with respect to multiplexing {see note 
2). 



During the resynchronization {see 6.14) and reassignment 
after failure (see 6.12) procedures, the initiator may reassign 
a transport connection to another network connection 
joining the same NSAPs, provided that it is the owner of the 
network connection and that the transport connection is 
assigned to only one network connection at any given time. 

During the splitting procedure (see 6.23), a transport entity 
may assign a transport connection to any additional network 
connection joining the same NSAPs, provided that it is the 
owner of the network connection and that either the network 
connection does not have another transport connection 
assigned to it; or multiplexing is possible on the network 
connection. 

The transport entity that did not initiate the assignment 
becomes aware of the assignment when it receives: 

a) a CR TPDU during the connection establishment 
procedure (see 6.5); or 

b) an RJ TPDU or a retransmitted CR or DR TPDU 
during the resynchronization (see 6.14) and 
reassignment after failure (see 6.12) procedures; or 

c) any TPDU when splitting (see 6.23) is used. 
NOTES 

1 When a new network connection is created, the quality of 
service requested is a local matter, although it will normally be 
related to the requirements of transport connection(s) expected to 
be assigned to it, 

2 An existing network connection may also not be suitable if, tor 
example, the quality of service requested for the transport 
connection cannot be attained by using or enhancing the network 
connection. 

3 A network connection with no transport connection(s) assigned 
to it, may be available after initial establishment, or because all of 
the transport connections previously assigned to it have been 
released. It is recommended that only the owner of such a network 
connection should release it. Furthermore, it is recommended that 
it not be released immediately after the transmission of the final 
TPDU of a transport connection; either a DR TPDU in response to 
CR TPDU or a DC TPDU in response to DR TPDU. An 
appropriate delay will allow the TPDU concerned to reach the other 
transport entity allowing the freeing of any resources associated 
with the transport connection concerned. 

4 After the failure of a network connection, transport connecfions 
which were previously multiplexed together may be assigned to 
different network connections, and vice versa. 
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6.1.2 Transmission over CLNS 

This procedure is used only when operating over the 
connectionless-mode network service. 



6.1.2.1 Purpose 

The procedure is used to transmit 
connectionless-mode network service. 



TPDUs over the 



6.1.2.2 Network service primitives 

The procedure makes use of the following network service 
primitive: 

N-UNITDATA. 



6.1.2.3 



Procedure 



Each TPDU shall be transmitted in a single invocation of 
the connectionless-mode network service, over a pre- 
existing association between a pair of NSAPs. The 
association is considered by transport entities as 
permanently established and available. 

6.2 Transport protocol data unit (TPDU) transfer 

6.2.1 Purpose 

The TPDU transfer procedure is used in all classes to 
convey transport protocol data units in user data fields of 
network service primitives. 

6.2.2 Network service primitives 

The procedure uses the following network service primitives 
when operating over CONS: 

a) N-DATA; 

b) N-EXPEDITED DATA. 

The procedure uses the following network service primitive 
when operating over CLNS: 

N-UNITDATA. 



TPDUs as NS-user data parameters of N-EXPEDITED 
DATA primitives. 

In all other cases, transport entities shall transmit and 
receive TPDUs as NS-user data parameters of N-DATA 
primitives. 

When a TPDU is put into an NS-user data parameter, the 
significance of the bits within an octet and the order of 
octets within a TPDU shall be defined in 13.2. 

NOTE - TPDUs may be concatenated (see 6.4). 
6.3 Segmenting and reassembling 

6.3.1 Puipose 

The segmenting and reassembling procedure is used in all 
classes to map TSDUs onto TPDUs. 

6.3.2 TPDU and Paranieter Used 

The procedure makes use of the following TPDU and 
parameter: 

DT TPDU 

- EndofTSDU. 



6.3.3 



Procedure 



A transport entity shall map a TSDU onto an ordered 
sequence of one or more DT TPDUs. This sequence shall 
not be interrupted by other DT TPDUs on the same 
transport connection. 

All DT TPDUs except the last DT TPDU in a sequence 
greater than one shall have a length of data greater than 
zero. 

NOTES 

1 The EOT parameter of a DT TPDU indicates whether or not 
there are subsequent DT TPDUs in the sequence. 

2 There is no requirement that the DT TPDUs shall be of the 
maximum length selected during connection establishment. 

6.4 Concatenation and separation 



6.2.3 



Procedure 



The transport protocol data units (TPDUs) defined for the 
protocol are listed in 4.2. 

When operating over CLNS, the transport entities shall 
transmit and receive all TPDUs as NS-user data parameters 
of N-UNITDATA primitives. 

When operating over CONS and when the netv.'ork 
expedited variant has been selected for class 1, the 
transport entities shall transmit and receive ED and EA 



6.4.1 Purpose 

The procedure for concatenation and separation is used in 
classes 1, 2, 3 and 4 to convey multiple TPDUs in one 

NSDU. 



6.4.2 



Procedure 



A transport entity may concatenate TPDUs from the same 
or different transport connections, while maintaining the 
order of TPDUs for a given transport connection pompatible 
with the protocol operation. 
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A valid set of concatenated TPDUs may contain 

a) any number of TPDUs from the following list: AK, 
EA, RJ. ER, DC TPDUs, provided that these TPDUs 
come from different transport connections; 

b) no more than one TPDU from the following list: CR, 
DR, CC, DT, ED TPDUs; if this TPDU is present, it shall 
be placed last in the set of concatenated TPDUs. 

A transport entity shall accept a valid set of concatenated 
TPDUs. 

NOTES 

1 The TPDUs within a concatenated set may be disfinguished by 
means of the length Indicator parameter. 

2 The end of a TPDU containing data is indicated by the 
termination of the NSDU. 

3 When operating over CONS the number of concatenated 
TPDUs referred to in 6.4.2.a) is bounded by the maximum number 
of transport connections which are multiplexed together except 
during assignment or reassignment. 

When operating over CLNS, the number of TPDUs that may be 
concatenated is bounded by the number of transport connections 
established between two NSAPs and/or the maximum available 
NSDU size. 

6.5 Connection establishment 

6.5.1 Purpose 

The procedure for connection establishment is used in all 
classes to create a new transport connection. 

6.5.2 Network service primitives 

When operating over CONS, the procedure uses the 
following network service primitive: 

N-DATA. 

When operating over CLNS, the procedure uses the 
following network service primitive: 

N-UNITDATA. 

6.5.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) CRTPDU 

- CDT; 

- DST-REF (set to zero); 

- SRC-REF; 



- CLASS and OPTIONS (i.e. preferred class, use 
of extended format, non-use of explicit flow control in 
class 2); 

- calling TSAP-ID; 

- called TSAP-ID; 

- TPDU size (proposed); 

- preferred maximum TPDU size (proposed); 

- version number; 

- protection parameter; 

- checksum; 

- additional option selection (i.e. use of network 
expedited in class 1, use of receipt confirmation in 
class 1, non-use of checksum in class 4, use of 
transport expedited data transfer service, use of 
selective acknowledgement, use of request 
acknowledgement); 

- alternative protocol class(es); 

- acknowledgement time; 

- Inactivity time; 

- throughput (proposed); 

- residual error rate (proposed); 

- priority (proposed); 

- transit delay (proposed); 

- reassignment time; 

- user data; 

b) CCTPDU 

- CDT; 

- DST-REF; 

- SRC-REF; 

- CLASS and OPTIONS (selected); 

- calling TSAP-ID; 

- called TSAP-ID; 

- TPDU size (selected); 

- the preferred maximum TPDU size (selected); 

- protection parameter; 

- checksum; 

- additional option selection (selected); 

- acknowledgement time; 

- Inactivity time; 

- throughput (selected); 

- residual error rate (selected); 

- priority (selected); 

- transit delay (selected); 

- user data. 
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6.5.4 Procedure for operating over CONS 

A transport connection is established by means ot one 
transport entity (the initiator) transmitting a CR TPDU to the 
other transport entity (the responder), which replies with a 
CC TPDU. 

Before sending the CR TPDU, the initiator assigns the 
transport connection being created to one (or more if the 
splitting procedure is being used) network connection(s). It 
is this set of networi< connections over which the TPDUs are 
sent. 

NOTE - Even if the initiator assigns the transport connection to 
more than one network connection, all the CR TPDUs (if repeated) 
or DR TPDUs with DST-REF set to zero which are sent prior to the 
receipt of the CC TPDU shall be sent on the same network 
connection, unless an N-DISCONNECT indication Is received. 
(This is necessary because the remote entity may not support class 
4 and therefore may not recognize splitting.) If the initiator has 
made other assignments, it will us© them only after receipt of a 
class 4 CC TPDU (see also the splitting procedure 6.23). 

During this exchange, all information and parameters 
needed for the transport entities to operate shall be 
exchanged or negotiated. 

NOTE - Except in class 4, it is recommended that the initiator starts 
an optional timer TS1 at the time the CR TPDU is sent. This timer 
should be stopped when the connection is considered as accepted 
or refused or unsuccessful. If the timer expires, the initiator should 
reset or disconnect the networtt connection, and in classes 1 and 3, 
freeze the reference (see 6.18). For all other transport 
connection(s) multiplexed on the same network connection, the 
procedures for reset or disconnect as appropriate should be 
folk>wed. 

When an unexpected duplicated CR TPDU is received (with 
class 4 as preferred clas's) it shall be ignored in classes 0, 1, 
2, and 3 and a CC TPDU shall be returned in class 4. 

After -receiving the CC TPDU for a class which includes the 
procedure for retention until acknowledgement of TPDUs 
the initiator shall acknowledge the CC TPDU as defined in 
Table 5 (see 6.13). 

When the network expedited variant of the expedited data 
transfer (see 6.11) has been agreed (possible in class 1 
only), the responder shall not send an ED .TPDU before the 
CC TPDU is acknowledged. 

The following information is exchanged: 

a) references: Each transport entity chooses a 
reference to be used by the peer entity which is 16 bits 
long and which is arbitrary under the following 
restrictions: 

1) it shall not already be in use nor frozen (see 
6.18), 

2) it shall not be zero. 

This mechanism is symmetrical and provides 
identification of the transport connection independent of 



the network connection. The range of references used 
for transport connections, in a given transport entity, is a 
local matter. 

b) calling and called TSAP-IDs (optional): when either 
network address unambiguously defines the transport 
address this information may be omitted. 

c) initial credit: Only relevant for classes which include 
the explicit flow control function. 

d) user data: Not available if class is the preferred 
class (see the note). Up to 32 octets in other classes. 

NOTE — If class is a valid response according to table 3, 
inclusion of user data in the CR TPDU may cause the 
responding entity to refuse the connection (for example if it only 
supports class 0). 

e) acknowledgement time: Only in class 4. 

f) checksum parameter; Only in class 4. 

g) protection parameter: This parameter and its 
semantics are user defined. 

h) inactivity time: Only in class 4. The inactivity time 
parameter shall not be included in a CC TPDU if it was 
not present in the corresponding CR TPDU. 

The following negotiations take place: 

j) protocol class: The initiator shall propose a preferred 
class and may propose any number of alternative 
classes which permit a valid response as defined in 
table 3. The initiator should assume when it sends the 
CR TPDU that its preferred class will be agreed to, and 
commence the procedures associated with that class, 
except that it class or class 1 is an alternative class, 
multiplexing shall not commence until a CC TPDU 
selecting the use of classes 2, 3 or 4 has been received. 

NOTE — This means, for example that when the preferred 
class includes resynchronizaticn (see 6.14) the 
resynchronization will occur if a reset is signalled during 
connection establishment. 

The responder shall select one class defined in table 3 
as a valid response corresponding to the preferred class 
and to the class(e3), it any, cor.lained in the alternative 
class paramerer of the CR ""?rj. It shall indicate the 
selected cl ss In Jhe CC IPC -J and- shall follow the 
procedures lOr trie selncted class. 

If '.ns 'prt;f erred class is not selected, then on receipt of 
the CC TPDU the initiator shall adjust its 'Operation 
according to the procedures'of the selected class. 

NOTES 

1 The valid responses indicated in table 3 result from both 
explicit negotiation, whereby each of the classes proposed is a 
valid response, and implicit negotiation whereby 

a) If class 3 or 4 is proposed then class 2 is valid response; 
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Table 3 - Valid responses corresponding to the preferred class and 
any alternative class proposed in the CR TPDU 



Preferred 
class 





1 


Alternative class 
2 3 


4 


none 





not valid 


not valid 


not valid 


not valid 


• not valid 


class 


1 


class. 1 or 


class 1 or 


not valid 


not valid 


not valid 


class 1 orO • 


2 


■ class 2 or 


not valid 


class 2 


not valid 


not valid 


class 2 


3 


class 3, 2 or 


class 3, 2, 1 or 


class 3 or2- 


class 3 or 2 


not valid 


class 3 or 2 


4 


class 4, 2 or 


class 4, 2, 1 or 


class 4 or 2 


class 4, 3 or 2 


class 4 or 2 


class 4 or 2 



b) if class 1 is proposed then class is a valid response. 

2 Negotiation from class 2 to class 1 and from any class to an 
higher-numbered class is not valid. 

3 Redundant combinations are not a protocol error. 

k) TPDU size: The initiator nnay propose a maximunn 
size for TPDUs, and the responder nnay accept this 
value or respond with any value between 128 and the 
proposed value in the set of values available (see 13.3.4 

'^)- 

NOTE — The length of the CR TPDU does not exceed 128 
octets (see 13.3). 

m) preferred maxinnum TPDU size; The value of this 
parameter, multiplied by 128, yields the proposed or 
accepted maximum TPDU size in octets. The initiator 
may proposed a preferred maximum size for TPDUs and 
the responder may accept this value or respond with a 
smaller value. 

NOTE - If this parameter is used in a CR TPDU without also 
including the TPDU size parameter, this will result in a 
maximum TPDU size of 128 octets being selected if the remote 
entity does not recognize the preferred TPDU size parameter. 
Therefore, it is recommended that both parameters be included 
in the CR TPDU, 

If the preferred maximum TPDU size parameter is 
present in a CR TPDU the responder shall 

either: ignore the preferred maximum TPDU size 
parameter and follow TPDU size negotiation as 
defined in 6.5.4 l<); 

or: use the preferred maximum TPDU size 
parameter to determine the maximum TPDU size 
requested by the initiator and ignore the TPDU size 
parameter. In this case the responder shall use the 
preferred maximum TPDU size parameter in the CC 
TPDU and shall not include the TPDU size 
parameter in the CC TPDU. 

If the preferred maximum TPDU size parameter is not 
present in the CR TPDU it shall not be included in the 
corresponding CC TPDU. In this case TPDU size 
negotiation is as defined in 6.5.4 k). 



n) normal or extended format: Either normal or 
extended is available. When extended is used this 
applies to CDT, TPDU-NR , ED-TPDU-NR, YR-TU-NR 
and YR-EDTU-NR parameters. 

p) checksum selection: This defines whether or not 
TPDUs of the connection are to include a checksum. 

q) quality of service parameters: This defines the 
throughput, transit delay, priority and residual error rate. 

NOTE — The transport service defines transit delay as 
requiring a previously stated average TSDU size as a basis for 
any specification. This protocol as specified in 13.3.4 p), uses 
a value at 128 octets. Conversion to and from specifications 
based upon some other value is a local matter. 

r) the non-use of explicit flow control in class 2. 

s) the use of network receipt confirmation and network 
expedited when class 1 is to be used. 

t) use of expedited data transfer service: This allows 
both TS-users to negotiate the use or non-use of the 
expedited data transport service as defined in the 
transport service (see ISO 8072). 

u) the use of selective acknowledgement: This allows 
the transport entities to decide whether to use 
procedures that allow acknowledgement of DT TPDUs 
that are received out-of-sequence (orily in class 4). 

v) the use of request acknowledgement: This allows 
both transport entities to negotiate the use or non-use of 
the request acknowledgement facility specified in 
6.13.4.2 (only in classes 1, 3, 4). 

The following information is sent only in the CR TPDU: 

w) version number: This defines the version of the 
transport protocol standard used for this connection. 

x) reassignment time parameter: This indicates the 
time for which the initiator wiH persist in following the 
reassignment after failure procedure. 
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The negotiation rules for the options are such that the 
initiator may propose either to use or not to use the option. 
The responder may either accept the proposed choice or 
select an alternative choice as defined in table 4. 

When a parameter [which is valid tor the proposed 
class(es)] is absent and a default value is defined in this 
International Standard, this is equivalent to the presence of 
the parameter with the default value. 

In class 2, whenever a transport entity requests or agrees to 
the transport expedited data transfer service or to the use of 
extended formats, it shall also request or agree 
(respectively) to the use of explicit flow control. 

Table 4 - Negotiation of options during connection 
establishment 



Option 


Proposal 

made by the 

initiator 


Valid selection 

by the 

responder 


Transport expedited data 
transfer service 
(classes 1,2, 3, 4 only) 


Yes 

No 


Yes or No 
No 


Use of receipt confirmation 
(class 1 only) 


Yes 
No 


Yes or No 
No 


Use of the network 

expedited 

variant (class 1 only) 


Yes 
No 


Yes or No 
No 


Non-use of checksum 
(class 4 only) 


Yes 
No 


Yes or No 
No 


Non-use of explicit flow 

control 

(class 2 only) 


Yes 
No 


Yes or No 
No 


Use of extended format 
(classes 2, 3,4 only) 


Yes 

No 


Yes or No 
No 


Use of selective 
acknowledgement (class 4 
only) 


Yes 
No 


Yes or No 
No 


Use of request 
acknowledgement (classes 
1,3, 4 only) 


. Yes 
No 


Yes or No 
No 



NOTE - Table 4 defines the procedures for negotiation of options. 
This negotiation has been designed such that if the initiator 
proposes the mandatory implementation option specified in clause 
14, the responder has to accept use of this option over the transport 
connection except for the use of the transport expedited data 
transfer service which may be rejected by the TS-user. If the 
initiator proposes a non-mandatory implementation option, the 
responder is entitled to select use of the mandatory implementation 
option for use over the transport connection. 

6.5.S Procedure for operating over CLNS 

A transport connection is established by means of one 
transport entity (the initiator) transmitting a CR TPDU to the 
other transport entity (the responder), which replies with a 
CC TPDU. During this exchange, all information and 



parameters needed for the transport entities to operate shall 
be exchanged or negotiated. When an unexpected 
duplicated CR TPDU is received {with class 4 as preferred 
class) a CC TPDU shall be returned. 

After receiving the CC TPDU, the initiator shall 
acknowledge the CC TPDU as defined in table 5 (see 
6.13). 

The following information is exchanged: 

a) references: Each transport entity chooses a 
reference to be used by the peer entity which is 16-bits 
long and which is arbitrary under the following 
restrictions: 

1) it shall not already be in use nor frozen (see 
■ 6.18). 

2) it shall not be zero. 

This mechanism is symmetrical and provides 
identification of the transport connection itself. The 
range of references used for transport connections, in a 
given transport entity, is a local matter. 

b) called and calling TSAP-IDs (optional): Indicates the 
calling and called transport service access points. When 
either the network address unambiguously defines the 
transport address, this information may be omitted. 

c) initial credit. 

d) user data: up to 32 octets. 

e) acknowledgment time. 

f) checksum parameter. 

g) protection parameter: This parameter and its 
semantics are user defined. 

h) inactivity time: The inactivity time parameter shall 
not be included in a CC TPDU if it was not present in the 
corresponding CR TPDU. 

j) protocol class: Class 4 is the only valid value for the 
preferred protocol class proposed by the initiator, and for 
the class selected by the responder. An alternative 
class is not permitted. 

The following negc jations takb place: 

k) TPDU size: The initiator may propose a maximum 
size for TPDUs in the set of values available [see 1 3.3.4 
b)]. This value may be limited by the maximum available 
NSDU size if known, and cannot exceed the maximum 
NSDU. size for connectionless-mode network service as 
defined in iSO/lEC 8348. The responder may accept 
this value or respond with any value between 128 and 
the proposed value in the set of values available [see 
13.3.4 b)]. 

NOTES 
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1 The length of the CR TPDU does not exceed i28 octets 
(see 13.3). 

2 The transport eiitities may have knowledge, by some local 
means, of the maximum available NSDU size, 

m) preferred maximum TPDU size: The value of this 
parameter, multiplied by 128, yielcis the proposed or 
accepted maximum TPDU size in octets. The initiator 
may propose a preferred maximum size for TPDUs and 
the responder may accept this value or respond with a 
smaller value. 

MOTE - if ^is paratnater is liSQfi in a CR TPDU without also 
indudiny the TPDU size parameter, this will result in a 
maxirmurr. TPOU aza of I2fl octets being Etlacted if the remote 
entity does not reccgn!2<=! the preferred TPDU size parameter. 
Therefore, it is recomniended that both parameters be included 
in the CR TPDU. 

If the preferred maximum TPDU size parameter is 
present in a CR TPDU fhe responder shall 

estlisr: ignore The praferrsd maximum TPDU size 
paramete'' and I'oliow TPDU size negotiation as 
defined in G.5.5 k); 

or: use the preferred maximum TPDU size 
parameter to determine the maximum TPDU size 
requested by the Iniijaior and ignore the TPDU size 
parariieter in this case the responder shall use the 
Dreferred r(^aximi!m fPDU size parameter in the CC 
TPDU and shaii not include the TPDU size 
parameter in the CC TPDU. 

if the preferred maximum TPDU size parameter is not 
present in the CR TPDU it shall not be included in the 
corresponding CC TPDU. In this case TPDU size 
negotiation is as defined in 6.5.5 k). 

n) nomnal or extended format: Either normal or 
ex1ef>ded is available. When extended is used this 
applies to COT TPDU-NR, ED TPDU-NR, YR-TU-NR 
anci YR-ED i U-.NR parameters. 

p) checksum selection: This defines whether or not 
TFDUs of the connection are to include a checksum. 

q) quality of service parameters: This defines the 
throughput, transit delay, priority and residual error rate. 

NOTE - The transport service defines transit delay as requiring 
a previously stated average TSDU size as a basis for any 
specification. This protocol as specified in 13.3.4 p), uses a 
value at 128 octets. Conversion to and from specifications 
based upon Some other value is a local matter. 

r) use of expedited data transfer service; This allows 
both TS'Users to negotiate the use or non-use of the 
expedited data transport service as defined in the 
transport service (ISO 8072). 

s) the use of selective acknowledgement: This allows 
the transport entities to decide whether to use 
procedures that allow acknowledgement of DT TPDUs 
that are received out-of-sequence. 



t) the use of request acknowiedgement: This allows 
both transport entities to negotiate the use or non-use of 
the request acknowledgement facility specified in 
6.13.4.2. 

The following information is sent only in the CR TPDU: 

u) version number: This defines the version of the 
transport protocol standard used for this connection. 

6.6 Connection refusal 

6.6.1 Purpose 

The connection refusal procedure is used in all classes 
when a transport entity refuses a transport connection in 
response to a CR TPDU. 

6.6.2 TPDUs and parameters used 

The procedure uses tfje follow TPDUs and parameters: 

a) DRTPDU 

- SRC-REF; 

- reason; 

- user data; 

b) ERTPDU 

- reject cause; 

- invalid TPDU. 



6.6.3 



Procedure 



If a transport connection cannot be accepted, the responder 
shall respond to the CR TPDU with a DR TPDU. The 
reason shall indicate why the connection was not accepted. 
The source reference field in the DR TPDU shall be set to 
zero to indicate an unassigned reference. 

If a DR TPDU is received the initiator shall regard the 
connection as released. 

The responder shall respond to an invalid CR TPDU by 
sending an ER or DR TPDU. If an ER TPDU is received in 
response to a CR TPDU, the initiator shall regard the 
connection as released. 

NOTES 

1 When the invalid CR TPDU can be identified as having class 
as the preferred class, it is recommended to respond with an ER 
TPDU. For all other invalid CR TPDUs either an ER TPDU or DR 
TPDU may be sent. 

2 If the optional supervisory timer TS1 has been set tor this 
connection then the initiator should stop the timer on receipt of the 
DR or ERTPDU. « 

3 It is a local matter whether the initiator releases the networt^ 
connection it no transport connections are now assigned to it. 
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6.7 Normal release 

6.7.1 Normal release when operating over CONS 

6.7.1.1 Purpose 

The release procedure is used by a transport entity in order 
to terminate a transport connection. The implicit variant is 
used only in class 0. The explicit variant is used in classes 
1,2, 3 and 4. 

NOTES 

1 When the implicit variant is used (i.e. in class 0), the lifetime of 
the transport connection is directly correlated with the lifetime of the 
network connection. 

2 The use of the explicit variant of the release procedure enables 
!he transport connection to be released independently of the 

underlying networtc connection. 

6.7.1.2 Network service primitives 

The procedure uses the following network service 
primitives: 

a) N-DISCONNECT, 

b) N-DATA. 

6.7.1.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters 

a) DRTPDU 

- reason; 

- user data; 

- SRC-REF; 

- DST-REF; 

b) DCTPDU. 

6.7.1 .4 Procedure for implicit variant 

In the implicit variant either transport entity disconnects a 
transport connection by disconnecting the network 
connection to which it is assigned. When a transport entity 
receives an N-DISCONNECT this should be considered as 
the release of the transport connection. 



6.7.1.5 



Procedure for explicit variant 



When the release o1 a transport connection is to be initiated, 
a transport entity 

a) if it has previously sent or received a CC TPDU (see 
note 1) shall 

1) send a DRTPDU; 



2) discard all subsequently received TPDUs other 
than a DR or DCTPDU; 

3) consider the transport connection released on 
receipt of a DR or DC TPDU; 

b) If a) is not applicable and if there is an outstanding 
CR TPDU, it shall 

1) for classes other than class 4 wait for the 
acknowledgement of the outstanding CR TPDU; if it 
receives a CC TPDU, is shall follow the procedures 
in6.7.1.5.a). 

2) for class 4 either send a DR TPDU with a zero 
value in the DST-REF field or follow the procedure in 
6.7.1.5.b)1. In the former case further receipt of a 
CC TPDU specifying class 4 will be ignored. Receipt 
of CC TPDU with another class will be processed as 
follows; If the class is the network connection shall 
be disconnected, otherwise a DR TPDU with the 
DST-REF field set to the value of the SRC-REF field 
of the received CC TPDU shall be sent and the 
release procedure of the class is continued. 

A transport entity that receives a DR TPDU shall 

c) If it has previously sent a DR TPDU for the same 
transport connection, consider the transport connection 
released; 

d) If it has previously sent a CR TPDU that has not 
been acknowledged by a CC TPDU, consider the 
connection refused (see 6.6)^ 

if the SRC-REF is not zero a DC TPDU shall be sent 
using the SRC-REF as the DST-REF; 

NOTE - In this case the DR has been associated regardless of 
its SRC-REF field (see 6.9.1 .4 and 6.9.2.4). 

e) if c) and d) are not applicable, send a DC TPDU and 
consider the transport connection released. If the 
received DR has the DST-REF field set to zero, then a 
DC with SRC-REF set to zero shall be sent, regardless 
of the local reference. 

NOTE - If the entity receiving such a DR TPDU has previously 
decided to negotiate down the class, this entity is always 
entitled ■> consider such a DR TPDU as spurious. Since no 
association has been made the transport connection is not 
released at the responder side but the CC TPDU, when sent, 
will be answered by a DR TPDU (spurious CC TPDU), 

NOTES 

1 This requirement ensures that the transport entity is aware of 
the remote reference for the transport connection. 

2 When the transport connection is considered as released the 
local reference is either available for re-use or is frozen (see 6.18). 

3 After the release of a transport connection the network 
connection can be released or retained to enable its re-use for the 
assignment of other transport connections {s<^& 6.1-.1). 
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4 Except in class 4, it is recommended that, if a transport entity 
does not reteive acknowledgement of a DR TPDU within time TS2, 
it should either reset or disconnect the network connection, and 
freeze the reference when appropriate (see 6.18). For all other 
transport conn6Ction(s) multiplexed on this network connection the 
procedures for reset or disconnect as appropriate should be 
followed. 

5 When a transport entity is waiting for a CC TPDU before 
sending a DR TPDU and the network connection is reset or 
released, it should consider the transport connection released and, 
in classes other than classes and 2, freeze the reference (see 
6.18), 

6.7.2 Normal release when operating over CLNS 

6.7.2.1 Purpose 

The release procedure is used by a transport entity in order 
to terminate a transport connection. 

6.7.2.2 Network service primitives 

The procedures makes use of the following network service 
primitive: 

N-UNITDATA. 

6.7.2.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) DR TPDU; 

- reason; 

- user data; 

- SRC-REF; 

- DST-REF; 

b) DC TPDU. 



6.7.2.4 



Procedure 



When the release of a transport connection is to be initiated, 
a transport entity shall send a DR TPDU and shall discard 
all subsequently received TPDUs except for a DR or a DC 
TPDU. 

On the receipt of a DR or a DC TPDU, it shall consider the 
transport connection to be released and the local reference 
shall be frozen (see 6.18). If a CC TPDU has been 
previously sent or received by the transport connection, 
then the remote reference is known and shall be used for 
the DST-REF in the DR TPDU to be sent. If the remote 
reference is not known, then the DST-REF in the DR TPDU 
may be set to zero, or the entity may wait until a CC TPDU 
is received before sending the DR TPDU. 

NOTE - In case that the er% decides to wait for the arrival of the 
CC TPDU for the connection, deadlock could result from a CC 
TPDU that nsver arrives. Such a deadlock is prevented by the 



expiration of the CR TPDU retransmission counter, which forces the 
DR TPDU to be sent. 

A transport entity which receives a DR TPDU shall 

a) consider the transport connection to be released if it 
has previously sent a DR TPDU for that connection; 

b) consider the transport connection to be refused (see 
6.6) if it has previously sent a CR TPDU for that 
connection and no CC TPDU has been received in 
acknowledgment; 

c) consider the transport connection to be released and 
send a DC TPDU in all other cases, if the received DR 
TPDU has the DST-REF field set to zero, then a DC 
TPDU with SRC-REF set to zero shall be $ent, regard 
less of the local reference. 

6.8 Error release when operating over CONS 

6.8.1 Purpose 

This procedure is used only in classes and 2 to release a 
transport connection on the roceipt of an N-DISCONNECT 
or N-RESET indication. 

6.8.2 Network service primitives 

The procedure uses the following service primitives: 

a) N-DISCONNECT request; 

b) N-DISCONNECT indication; 

c) N-RESET indication; 

d) N-RESET response. 

6.8.3 Procedure 

When, on the network connection to which a transport 
connection is assigned, an N-DISCONNECT or N-RESET 
indication is received, both transport entities shall consider 
that the transport connection is released and so inform the 
TS-users. 

On receipt of an N-RESET indication: 

- in class 0, an N-DISCONNECT request shall be 
issued; 

- in class 2, it is a local choice to issue an N-RESET 
response or an N-DISCONNECT request; one of these 
primitives shall be issued. However, if the Network 
Connection has other Transport Connections of a 
different class assigned to it, the error recovery 
procedure of that class shall be used to determine which 
primitive is issued. 
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6.9 Association of TPDUs with transport connections 

6.9.1 Association of TPDUs with transport 
connections when operating over CONS 



6.9.1.1 



Purpose 



This procedure is used in all classes to interpret a received 
NSDU as TPDU(s) and, if possible, to associate each such 
TPDU with a transport connection. 



6.9.1.2 



Network service primitives 



The procedure uses the following network service 
primitives: 

a) N-DATA indication; 

b) N-EXPEDITED DATA indication; 

c) N-RESET request; 

d) N-DISCONNECT request. 

6.9.1.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) any TPDU except CR TPDU, DT TPDU in classes 
or 1 and AK TPDU in class 1 

- DST-REF; 

b) CR, CC, OR and DC TPDUs 

- SRC-REF; 

c) DT TPDU in classes or 1 and AK TPDU in class 1 . 

6.9.1.4 Procedures 



6.9.1.4.1 



Identification of TPDUs 



If the received NSDU or expedited NSDU cannot be 
decoded (i.e. does not contain one or more correct TPDUs) 
or is corrupted (i.e. contains a TPDU with a wrong 
checksum) then the transport entity shall 

a) if the network connection on 'which the error is 
detected has a class or 1 transport connection 
assigned to it, treat as a protocol error (see 6.22) for that 
transport connection;- 

b) otherwise: 

1) if the NSDU can be decoded but contains 
corrupted TPDUs, discard the TPDUs (class 4 only) 
and optionally apply 6,9.1 .4.1 b)2); 

2) if the NSDU cannot be decoded issue an N- 
RESET or N-DISCONNECT request for the network 
connection and for all the transport connections 



assigned to this network connection (if any), apply 
the procedures defined for handling of network 
signalled reset or disconnect. 

If the NSDU can be decoded and is not corrupted, the 
transport entity shall 

a) if the network connection on which the NSDU was 
received has a class transport connection assigned to 
it, consider the NSDU as forming one TPDU and 
associate the TPDU with the transport connection (see 
6.9.1.4.2); 

b) otherwise, invoke the separation procedures and for 
each of the individual TPDUs in the order in which they 
appear in the NSDU apply the procedure defined in 
6.9.1.4.2. 



6.9.1.4.2 



Association of individual TPDU 



If the received TPDU is a CR TPDU, then if the SRC-REF 
parameter and the remote NSAP indicate an existing 
transport connection at that receiving entity, then the CR 
TPDU is associated with that transport connection, 
otherwise it is processed as requesting the creation of a 
new transport connection. 

If the received TPDU is a DT TPDU and the network 
connection has no TC assigned to it, and the DT TPDU is a 
class or class 1 TPDU (as recognized by the absence of a 
DST-REF field), then the TPDU should be ignored. 

Otherwise, the DST-REF parameter .of the TPDU is used to 
identify the transport connection. The following cases are 
distinguished: 

a) If the DST-REF is not allocated to a transport 
connection then no association with a transport 
connection is made and there are three cases: 

1) If the TPDU is a CC TPDU the transport entity 
shall respond on the same network connection with a 
DR TPDU. The SRC-REF of the "DR. TPDU may be 
either or the DST-REF from the received CC 
TPDU; 

2) If the TPDU is a DR TPDU the transport entity 
shall respond on the same network connection with a 
DC TPDU; except in the case that the DR is carrying 
a-SRC-REF get to zero, then no DC TPDU shall be 
sent, or in the case where the transport entity only 
supports class then the network connection shall 
be disconnected; 

3) If the TPDU is neither a CC or DR it shall be 
discarded; 

b) If the DST-REF is allocated to a transport 
connection, but the TPDU is received on a network 
connection to which this connection has not been 
assigned then there are four cases: 

1) if the transport connection is of class 4 and if the 
TPDU is received on a network connection with the 
same pair of NSAPs as that of the CR TPDU then 
the TPDU is associated with this transport 
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connection and considered as performing 
assignment; 

2) if the transport connection is not assigned to any 
network connection (waiting for reassignment after 
failure) and if the TI^DU is received on a networl< 
connection with the same pair of NSAPs as that of 
the CR TPDU then the association with that transport 
connection is made, except in the case of DC, DR 
and CC TPDUs which are respectively described in 
6.9.1.4.2 c), d),e); 

3) In classes 1 and 3, it is also possible to receive a 
TPDU performing reassignment prior to the 
notification of the disconnect of the current network 
connection (i.e. the transport connection is assigned 
to a network connection, but a TPDU containing the 
appropriate DST-REF is received on another network 
connection). In this case it is recommended that the 
transport entity: 

- issue an N-DISCONNECT request on the 
network connection to which the transport 
connection is currently assigned, 

- apply to all transport connections assigned to 
this network connection the procedure for 
processing a received N-DISCONNECT 
indication, 

- and then process the TPDU performing 
reassignment; 

4) otherwise, the TPDU is considered as having a 
DST-REF not allocated to a transport connection 
[case a)]; 

c) If the TPDU is a DC TPDU then it is associated with 
the transport connection to which the DST-REF is 
allocated, unless the SRC-REF is not the expected one, 
in which case the DC TPDU is discarded. 

d) if the TPDU is a DR TPDU then there are four cases: 

1) if the SRC-REF is not as expected then a DC 
TPDU with DST-REF equal to the SRC-REF of the 
received DR TPDU is sent back and no association 
is made, except that in the case where the transport 
entity only supports class and cannot transmit a 
DC TPDU, it disconnects the network connection 
instead of transmitting a DC TPDU; 

2) if a CR TPDU is unacknowledged then the DR 
TPDU is associated with the transport connection, 
regardless of the value of its SRC-REF parameter; 

3) if the transport entity implements class 4 and if 
the DST-REF is zero and there is an 
unacknowledged CC TPDU or T-CONNECT 
RESPONSE is awaited, then the DR TPDU shall be 
associated with the transport connection holding the 
SRC-REF as the remote reference; 

4) otherwise, the DR TPDU is associated with the 
transport connection identified by the DST-REF 
parameter; 

e) if the TPDU is a CC TPDU whose DST-REF 
parameter identifies an open connection (one for which 
a CC TPDU has been previously received), and the 
SRC-REF in the CC TPDU does not match the remote 



reference, then a DR TPDU is sent back with DST-REF 
equal to the SRC-REF of the received CC TPDU and no 
association is made. 

f) if none of the above cases apply then the TPDU is 
associated with the transport connection identified by the 
DST-REF parameter. 

6.9.2 Association of TPDUs with transport 
connections when operating over CLNS 



6.9.2.1 



Purpose 



This procedure is used to interpret a re-3ived NSDU as 
TPDU(s) and, if possible, to associate each such TPDU with 
a transport connection. 



6.9.2.2 



Network service primitives 



i his procedure makes use of the following network service 
primitive: 

N-UNiTDATA. 

6.9.2.3 TPDUs and parameters used 

This procedure makes use of the following TPDUs and 
parameters: 

a) all TPDUs except CR TPDU; 
-DST-REF; 

b) CR, CC, DR and DC TPDUs; 
- SRC-REF. 

6.9.2.4 Procedures 



6.9.2.4.1 



Identification of TPDUs 



If the received NSDU cannot be decoded (i.e., does not 
contain one or more correct TPDUs) or is corrupted (i.e., 
contains a TPDU with a wrong checksum) then the 
transport entity shall ignore (discard) the TPDUs. If the 
NSDU can be decoded and is not corrupted, the transport 
entity shall invoke the separation procedures and for each 
of the individual TPDUs in the order in which they appear in 
the NSDU apply the procedure in 6.9.2.4,2. 



6.9.2.4.2 



Association of individual TPDUs 



Association of a received TPDU with a transport connection 
is generally performed by attempting to match the DST-REF 
in the received TPDU and the NSAP pair over which it was 
received with those of an existing transport connection. 
There are three exceptions to this general procedure: when 
the received TPDU is a CR TPDU, the SRC-REF is used 
instead of the DST-REF; when the received TPDU is either 
a DR or a DC TPDU, the SRC-REF is used in addition to 
the DST-REF; and when the received TPIDU is a CC TPDU, 
whose DST-REF parameter identifies an open connection 
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(one for which a CC TPDU has been previously received), 
then the SRC-REF is used in addition to the DST-REF. 

The following actions shall be taken in consequence to the 
inability to match the TPDU io an existing transport 
connection: 

a) for a CR TPDU, a new transport connection shall be 
created. 

b) foraCC TPDU, a DR TPDU shall be sent using the 
SRC-REF and DST-REF from the received CC TPDU 
as the DST-REF and SRC-REF, respectively, of the DR 
TPDU. 

c) foraDR TPDU, there are four cases: 

1) if a CR TPDU is unacknowledged for the 
connection identified by the DST-REF in the DR 
TPDU, then the DR TPDU is associated with that 
connection regardless of the SRC-REF in the DR 
TPDU. 

2) if the CR TPDU for the connection identified by 
the DST-REF of thehas DRbeen 
acknowledged and the SRC-REF is not as expected, 
then a DC TPDU using the SRC-REF of the DR 
TPDU as DST-REF is sent and no association is 
made. 

3) if the DST-REF in the DR TPDU is zero and 
there is an unacknowledged CC TPDU or a T- 
CONNECT response is awaited for a transport 
connection holding remote reference equal to the 
SRC-REF of the DR TPDU, then the DR TPDU is 
associated with that transport connection. 

4) in all other situations, the DR TPDU is 
associated with the transport connection identified by 
the DST-REF of the DR TPDU. 

d) For all other TPDU types, the TPDU is discarded. 



6.10 Data TPDU numbering 

6.10.1 Purpose 

Data TPDU numbering is used in classes 1, 2 (except when 
the non-use of explicit flow control option is selected), 3 and 
4. Its purpose is to enable the use of recovery, flow control 
and resequencing functions. 

6.10.2 TPDUs and paranieters used 

The procedure uses the following TPDU and parameter: 

DT TPDU 

-• TPDU-NR. 

6.10.3 Procedure 

A transport entity shall allocate the sequence number zero 
to the TPDU-NR of the first DT TPDU which it transmits for 
a transport connection. For subsequent DT TPDUs sent on 
the same transport connection, the transport entity shall 



allocate a sequence number one greater than the previous 
one. 

When a DT TPDU is retransmitted, the TPDU-NR parameter 
shall have the same value as in the first transmission of that 
DTTPDU 

Modulo 2^ arithmetic shall be used when normal formats 
have been selected and modulo 2^' arithmetic shall be used 
when extended formats have been selected. In this 
international Standard the relationships "greater than" and 
"less than" apply to a set of contiguous TPDU numbers 
whose range is less than the modulus and whose starting 
and finishing numbers are known. The term "less than" 
means "occurring sooner in the window sequence" and the 
term "greater than" means "occurring later in the window 
sequence". 

6.1 1 Expedited data transfer 

6.11.1 Expedited data transfer when operating over 
CONS 

TPDU 

6.11.1.1 Purpose 

Expedited data transfer procedures are selected during 
connection establishment. The network normal data variant 
may be used in classes 1, 2, 3 and 4. The network 
expedited variant is only used in class "! . 

6.1 1 .1 .2 Network service primitives 

The procedure uses the following network service 
primitives: 

a) N-DATA; 

b) N-EXPEDITED DATA. 

6.11.1.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) ED TPDU 

- ED TPDU-NR; 

b) EATPDU 

- YR-EDTU-NR. 

6.11.1.4 Procedures 

The TS-user data parameter of each T-EXPEDITED DATA 
request shall be conveyed as the data field of an Expedited 
Data (ED) TPDU. 

Each ED TPDU received shall be acknowledged by an 
Expedited Acknowledge (EA) TPDU. 

No more than one ED TPDU shall remain unacknowledged 
at any time for each direction of a transport connection. 
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An ED TPDU with a zero length data field shall be treated 
as a protocol error. 

NOTES 

1 The network normal data variant is used, except when ttie 
network expedited variant (available in class 1 only), has been 
agreed, in which case ED and EA TPDUs are conveyed in the data 
fields of N-EXPEDITED DATA primitives (see 6.2.3). 

2 No TPDU can be transmitted using the network expedited 
variant until the CC TPDU becomes acknowledged, to prevent the 
network expedited variant from overtaking the CC TPDU. 

6.11.2 Expedited data transfer when operating over 
CLNS 



6.11.2.1 Purpose 

Expedited data transfer procedures are selected during 
connection establishment. 



6.1 1 .2.2 Network service primitives 

The procedure makes use of the following network service 
primitive: 

N-UNITDATA. 

6.11.2.3 TPDUs and parameters used 

The procedure makes use of the following TPDUs and 
parameters: 

a) ED TPDU; 

- EDTPDU-NR; 

b) EATPDU; 

- YR-EDTU-NR. 

6.11.2.4 Procedures 

The TS-user data parameter of each T-EXPEDITED DATA 
request shall be conveyed as the data field of an Expedited 
Data (ED) TPDU. 

Each ED TPDU received shall be acknowledged by an 
Expedited Acknowledge (EA) TPDU. 

No- more than one ED TPDU shall remain unacknowledged 
at any time for each direction of a transport connection. 

An ED TPDU with a zero length data field shall be treated 
as a protocol error (see 6.22). 



6.12 Reassignment after failure when operating over 
CONS 



6.12.1 Purpose 

The reassignment after failure procedure is used in classes 
1 and 3 to commence recovery from an NS-provider 
signalled disconnect. 

6.12.2 Network service primitives 

The procedure uses the following network service primitive: 
N-DISCONNECT indication 

6.12.3 Procedure 

When an N-DISCONNECt indication is received for the 
network connection to which a transport connectio.n is 
assigned, the initiator shall apply one of the following 
alternatives: 

a) if the TTR timer has not already run out and no DR 
TPDU is retained 

1) assign the transport connection to a different 
network connection (see 6.1.1) and start its TTR 
timer if not already started 

2) while waiting for the completion of assignment if 

- an N-DISCONNECT indication is received, 
repeat the procedure from 6. 12. 3. a); 

- the TTR timer expires, begin procedure 
6.12.3 b); 

3) when reassignment is complete perform active 
resynchronization by executing the procedure 
described in 6.14.4.1, and, if 6.14.4.1 b) has been 
performed, wait for the next event as follows: 

- if a valid TPDU is received as the result of the 
resynchronization, stop the TTR timer, or 

-■ if TTR runs out, wait for the next event, or 

- if an N-DISCONNECT indication is received, 
begin either procedure 6.12,3 a) or 6.12.3 b) 
depending on the TTR timer. 

NOTE - After TTR expires and while waiting for the next 
event, it is recommended that the initiator set a timer with a 
value equal to TWR. If this timer expires before the next 
event, the initiator should begin the procedure in 6.12.3 b). 

b) If the TTR timer has run out, consider the transport 
connection as released and freeze the reference (see 
6.18); 

c) if a DR TPDU is retained and the TTR timer has not 
run out, then follow the actions in either 6. 12. 3. a) or 
6.12.3.b). 
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The responder shall start its TWR timer if not already 
started. The arrival of the first TPDU related to the transport 
connection (because of resynchronization by the initiator) 
completes the reassignment after failure procedure. The 
TWR timer is stopped and the responder shall continue with 
resynchronization (see 6.14). If reassignment does not take 
place within this time, the transport connection is considered 
released and the reference is frozen (see 6.18). 

6.12.4 Timers 

The reassignment after failure procedure uses two timers: 

a) TTR, the time to try reassignment/resynchronization 
timer; 



b) TWR, the time to 
resynchronization timer. 



wait for reassignment/ 



The TTR timer is used by the initiator. Its value shall not 
exceed 2 min minus the sum of the maximum disconnect 
propagation delay and the maximum transit delay of the 
network connections (see note 1). The value for the TTR 
timer may be indicated in the CR TPDU. 

The TWR timer is used by the responder. If the 
reassignment time parameter is present in the CR TPDU, 
the TWR timer value shall be greater than the sum of the 
TTR timer plus the maximum disconnect propagation delay 
plus the maximum transit delay of the network connections. 

If the reassignment time parameter is not present in the CR 
TPDU, a default value of 2 min shall be used for the TWR 
timer. 

NOTES 

1 Provided that the required quality of service is met, TTR may be 
set to zero (i.e. no reassignment). This may be done, for example, 
if the rate of NS-provider generated disconnects is very low. 

2 Inclusion of the reassignment time parameter in the CR TPDU 
allows the responder to use a TWR value of less than 2 min. 

3 If the optional TSl and TS2 timers are used, it is recommended 

a) to stop TS1 or TS2 if running when TTR or TWR is started; 

b) to restart TSl or TS2 if necessary when the corresponding 
TPDU (CR TPDU or DR TPDU respectively) is repeated; 

c) to select for TS1 and TS2 values greater than TTR. 
6.13 Retention and acknowledgement of TPDUs 

6.13.1 Purpose 

The retention and acknowledgement of TPDUs procedure is 
used in classes 1, 3 and 4 to enable and minimize 
retransmission after possible loss of TPDUs. 



The confirmation of receipt variant is used only in class 1 
when it has been agreed during connection establishment 
(see the note). 

The AK variant is used in classes 3 and 4 and also in class 
1 when the confirmation of receipt variant has not been 
agreed during connection establishment. In addition, in 
Class 4, the option of using selective acknowledgement 
may be agreed to during connection establishment. 

The request acknowledgement procedure is selected during 
connection establishment and may be used in classes 3 and 
4, and in class 1 when the confirmation of receipt variant 
has not been agreed during connection establishment. It 
allows a transport entity. to request acknowledgement of 
retained DT TPDUs by setting the BOA parameter in a 
transmitted DT TPDU. 

NOTE - Use of the confirmation of receipt variant depends on the 
availability of the network layer receipt confirmation service and the 
expected cost reduction. 

6.13.2 Network service primitives 

When operating over CONS, the procedure uses the 
following network service primitives: 

a) N-DATA; 

b) N-DATA ACKNOWLEDGE. 

When operating over CLNS, the procedure uses the 
following network service primitive: 

N-UNITDATA. 

6.13.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) CR,CC,DR and DC TPDUs; 

b) AKTPDU 

- YR-TU-NR 

- selective acknowledgement parameters; 

c) RJTPDU 

- YR-TU-NR; 

d) DTTPDU 

- TPDU-NR; 

e) ED TPDU 

- ED-TPDU-NR; 

f) EATPDU 

- YR-EDTU-NR. 
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6.13.4 Procedures 

6.13.4.1 Retention until acknowledgement of TPDUs 

Copies of tfie following TPDUs shall be retained upon 
transmission to permit their later retransmission: 

CR, CC, DR, DT and ED TPDUs 

except in the following case: if a DR TPDU is sent in 
response to a CR TPDU there is no need to retain a copy of 
the DR TPDU. 

A copy of each of these TPDUs shall be retained until 

a) it is acknowledged, as specified in table 5; or 

b) the transport connection is released. 

6.1 3.4.2 Confirmation of receipt variant 

In the confirmation of receipt variant, applicable only in 
Class 1 , transport entities shall 

a) set the confirmation request parameter only if the 
data parameter contains a CC or DT TPDU (see notes 1 
and 2); 

b) issue an N-DATA ACKNOWLEDGE request when it 
receives an N-DATA indication with the confirmation 
request parameter set. 

6.13.4.3 Request of acknowledgement option 

If the request acknowledgement procedure has been 
negotiated, transport entities 

a) may request acknowledgennent of retained DT 
TPDUs by setting the ROA parameter in a transmitted 
DT TPDU. The decision as to when the sending 
transport entity should request acknowledgement is a 
local matter {see note 4). 

b) On receipt of a DT TPDU with the ROA parameter 
set shall transmit an AK TPDU containing up-to-date 
window information. 

6.13.4.4 Selective acknowledgement option 

If the selective acknowledgement option has been 
negotiated, transport entities 

a) may include selective acknowledgement parameters 
in a transmitted AK TPDU. These selective 
acknowledgement parameters, if included, shall contain 
acknowledgement of blocks of TPDUs not 
acknowledged by the YR-TU-NR field of the AK TPDU. 
This procedure allows transport entities to acknowledge 
DT TPDUs that are within the window but that are not in 
sequence. 



b) on receipt of an AK TPDU containing selective 
acknowledgement parameter(s) shall discard the DT 
TPDUs specified. 

NOTES (Notes 1 to 3 only apply when operating over CONS) 

1 It is a local matter for each transport entity to decide which N- 
, DATA requests should have the confirmation request parameter 

set. This decision will normally be related to the amount of storage 
available for retained copies of the DT TPDUs. 

2 Use of the confirmation request parameter may affect the 
quality of network service. 

3 In class 3, and in class 1, when use of explicit AK variant is 
selected, if a transport entity does not send an AK TPDU after 
reception of each DT TPDU, it is recommended that it 

- starts a timer after reception of DT TPDU; 

- sends an AK TPDU with up-to-date window information at 
expiration of the timer if an AK TPDU with the same window 
information has not been previously sent. 

Selection of the value of this timer is a local matter but may affect 
performance. 

4 If is recommended that, if the sending transport entity has a 
restriction in the number of DT TPDUs that it can retain, then it set 
the ROA parameter to avoid a delay in transmitting DT TPDUs due 
to the remote transport entity operating an AK withholding policy. 



Table 5 - Acknowledgement of TPDUs 



Retained 
TPDU 


Variant 


Retained until 
acknowledged by: 


CR 


Both 


CC, DRorERTPDU 


DR 


Both 


DC or DR (in case of collision) 

TPDU 


CC 


Confirmation 

of receipt 

variant 


N-DATA ACKNOWLEDGE 
indication, RJ, DT, EA or ED 
TPDU 


CC 


AK variant 


RJ, DT, AK, ED or EA TPDU 


DT 


Confirmation 

of receipt 

variant 


N-DATA ACKNOWLEDGE 
indication corresponding to an 
N-DATA request which 
conveyed, or came after, the 
DT TPDU 


DT 


AK variant 


AK or RJ TPDU for which the 
YR-TU-NR is greater than 
TPDU-NRintheDTTPDU. In 
case of selective 
acknowledgement, if the 
selective acknowledgement 
parameters in the AK TPDU 
include the TPDU-NR of the 
DTTPDU. 


ED 


Both 


EA TPDU for which the YR- 
EDTU-NRisequaltothe ED- 
TPDU-NRintheEDTPDU 
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6.14 Resynchronization 

6.14.1 Purpose 

The resynchronization procedures are used in classes 1 
and 3 to restore the transport connection to normal after a 
reset or during reassignment after failure according to 6.12. 

6.14.2 Network service primatives 

The procedure uses the following network service primitive: 
N-RESET indication. 

6.14.3 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) CR, DR, CC, and DC TPDUs; 

b) RJTPDU 

- YR-TU-NR; 

c) DTTPDU 

- TPDU-NR; 

d) EDTPDU 

- ED-TPDU-NR; 

e) EATPDU 

- YR-EDTU-NT. 

6.14.4 Procedure 

A transport entity which is notified of the occurrence of a N- 
RESET shall: 

a) if the transport entity is the responder, carry out the 
passive resynchronization procedure (see 6.14.4.2); 

b) if the transport entity has elected not to reassign, do 
nothing; 

c) otherwise, execute the active resynchronization 
procedure described in 6.14.4.1 and, if 6.14.4.1 b) has 
been performed, wart for the next event as follows: 

- if a valid TPDU is received as the result of the 
resynchronization, stop the TTR timer, or 

- if TTR runs out, wait for the next event, or 

- if an N-RESET indication is received, perform 
6.14.4. 

6.14.4.1 Active resynchronization procedures 

The transport entity shall carry out one of the following 
actions: 



a) if the TTR timer has been previously started and has 
run out (i.e. no valid TPDU has been received,), the 
procedures defined in 6.12.3 a)3) shall apply; 

b) othenwise, the TTR timer shall be started (unless it is 
already running) and the first which become applicable 
of the following actions shall be taken: 

1) it a CR TPDU is unacknowledged, then the 
transport entity shall retransmit it; 

2) if a DR TPDU is unacknowledged, then the 
transport entity shall retransmit it; 

3) otherwise, the transport entity shall carry out the 
data resynchronization procedures (6.14.4.3). 

6.14.4.2 Passive resynchronization procedures 

The transport entity shall not send any TPDUs until a TPDU 
has been received. The transport entity shall start its TWR 
timer if it has not already been started (due to a previous N- 
DISCONNECT or N-RESET indication). If the timer runs out 
prior to the receipt of a valid TPDU which commences 
resynchronization (i.e. CR or DR or ED or RJ TPDU) the 
transport connection is considered as released and the 
reference is frozen (see 6.18). 

When a valid TPDU is received the transport entity shall 
stop its TWR timer and carry out one of the following 
appropriate actions, depending on the TPDU: 

a) if it is a DR TPDU, then the transport entity shall 
send a DC TPDU; 

b) if it is a repeated CR TPDU (see note 1) the transport 
entity shall carry out the appropriate action from the 
following: 

1) if 3 CC TPDU has already been sent, and 
acknowledged; treat as a protocol error; 

2) if the responder wants to release the transport 
connection or refuse the CR TPDU: (re)transmit the 
DR TPDU, setting the source reference to zero; 

3) if the T-CONNECT response has not yet been 
received from the user: take no action; 

4) otherwise: (re)transmit the CC TPDU, followed 
by retransmission of any unacknowledged ED TPDU 
(see note 2) and retransmission of the 
unacknowledged DT TPDUs, subject to any 
applicable flow control procedures. 

NOTES 

1 A repeated CR TPDU can be identified by being on a 
network connection with the appropriate network addresses 
and having a correct source reference. 

2 The transport entity should not use network expedited 
until the CC TPDU is acknowledged (see 6.5). This rule 
prevents the network expedited from overtaking the CC 

TPDU. 
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c) if it is an RJ or ED TPDU then one of the following 
actions shall be taken: 

1) if a DR TPDU is unacknowledged, then the 
transport entity shall retransmit it; 

2) if a CC TPDU is unacknowledged, the RJ or ED 
TPDU shall be considered as acknowledging the CC 
TPDU, and the transport entity shall carry .out the 
data resynchronization procedures (6.14.4.3); 

3) otherwise, the transport entity shall carry out the 
data resynchronization procedures (6.14.4.3). 

6.14.4.3 Data resynchronization procedures 

The transport entity shall carry out the following actions in 
the following order: 

a) (re)transmit any ED TPDU which is unacknowledged. 

b) transmit an RJ TPDU with YR-TU-NR field set to the 
TPDU-NR of the next expected DT TPDU; 

c) wait for the next TPDU from the other transport 
entity, unless an RJ or DR TPDU has already been 
received; if a DR TPDU is received the transport entity 
shall send a DC TPDU, freeze the reference, inform the 
TS-user of the disconnection and take no further action 
[i.e. it shall not follow the procedures in 6.14.4-.3 d)]. If 
an RJ TPDU is received, the procedure of 6.14.4.3 d) 
shall be followed. If an ED TPDU is received the 
procedures as described in 6,1 1 shall be followed. If it is 
a duplicated ED-TPDU the transport entity shall 
acknowledge it with an EA.TPDU, discard the duplicated 
ED TPDU and wait again for the next TPDU; 

d) (re)transmit any DT TPDUs which are 
unacknowledged, subject to any applicable flow control 
procedures (see the note). 

NOTE -The RJ TPDU may have reduced the credit. 

6.15 Multiplexing and demultiplexing when operating 
over CONS 



6.15.1 Purpose 

The multiplexing and demultiplexing procedures are used in 
classes 2, 3 and 4 to allow several transport connections to 
share a network connection at the same time. 

6.15.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

CC, DR, DC, DT, AK. ED, EA, RJ. and ER TPDUs 
- DST-REF 



6.15.3 Procedure 

The transport entities shall be able to send and receive on 
the same network connection TPDUs belonging to different 
transport connections. 

NOTES 

1 When performing demultiplexing the transport connection to 
which the TPDUs apply Is determined by the procedures defined in 
6.9. 

2 Multiplexing allows the concatenation of TPDUs belonging to 
different transport connections to be transferred in the same N- 
DATA primitive (see 6.4). 

6.16 Explicit flow control 

6.16.1 Purpose 

The explicit flow control procedure is used in classes 2, 3, 
and 4 to regulate the flow of DT TPDUs independently of 
the flow control in the other layers. 

6.16.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) CR, CC, AK and RJ TPDUs 

- CDT; 

b) DTTPDU 

- TPDU-NR; 

- ROA; 

c) AKTPDU 

- YR-TU-NR; 

- subsequence number; 

- flow control confirmation; 

- selective acknowledgement parameters; 

d) RJTPDU 

r- YR-TU-NR. 

6.16.3 Procedure 

The procedures differ in different classes. They are defined 
in the clauses specifying the separate classes. 

6.17 Checksum 

6.17.1 Purpose 

The checksum" procedure is used to detect corruption of 
TPDUs by the NS-provider. 
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NOTE - Although a checksum algorithm has to be adapted to the 
type of errors expected on the network connection, at present, only 
one afgorithm is defined. 

6.17.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

All TPDUs 

- checksum. 

6.17.3 Procedure 

The checksum shall be used only in class 4. It shall always 
be used for the CR TPDU, and shall be used for all other 
TPDUs unless the non-use of the checksum was selected 
during connection establishment. 

The sending transport entity shall transmit TPDUs with the 
checksum parameter set such that the following formulae 

are satisfied: 

L 
Xa,= (modulo 255) 



L 



<3 (modulo 255) 



where 



/ is the number (i.e. position) of an octet within the 
TPDU (see 13.2); , 

a, is the value of octet in position r, 

L is the length of TPDU in octets. 

A transport entity which receives a TPDU (or a transport 
connection for which the use of the checksum has been 
agreed and which does not satisfy the above formulae shall 
discard the TPDU (see also note 2). 

When a spurious TPDU is received and an answer has to 
be sent, the transport entity shall 

a) if it. supports the checksum algorithm and the 
received TPDU contains a checksum parameter, include 
a checksum parameter in the answering TPDU; or 

b) in all other cases, not include a checksum parameter 
in the answering TPDU. 

An entity not supporting the checksum may always suppose 
that a CR TPDU with class 4 proposed is correct and 
therefore negotiate down to a class lower than 4. 

NOTES 

1 An efficient algorithm for determining the checksum parameters 
is given in annex B. 



2 If the checksum is incorrect, it is impossible to know with 
certainty to which transport connection the TPDU is related; further 
action may be required dependent on the type of network service in 
use (see 6.9.1 for CONS and 6.9.2 for CLNS). 

3 The checksum proposed is easy to calculate and so will not 
impose a heavy burden on implementations. However, it will not 
detect insertion or loss of leading or trailing zeros and will not detect 
some octets misordering. 

4 When CONS is used and a TPDU is received on a network 
connection, it is impossible to know with certainty that only class ^ 
transport connections use this network connection as it may tje a 
TPDU performing reassignment. 

Consequently, the only way to check the validity is as follows: 

a) if the network connection is used by a class or class 1 
transport connection, there is no checksum; 

b) examine the TPDU code; 

c) deduce the fixed part length; 

d) from LI, deduce the variable part; 

e) go through parameters and if the checksum parameter is 
found, then verify it; 

f) if it is incorrect, then assume that transport connection is 
class 4 and drop it; 

g) if it is correct, then associate the TPDU with a transport 
connection; if the transport connection uses the checksum, it is 
correct; otherwise, it shall be considered as a protocol error. 

6.18 Frozen relerences 

6.18.1 Purpose 

This procedure shall be used in order to prevent re-use of a 
reference while TPDUs associated with the old use of the 
reference may still exist. 

6.18.2 Procedure 

When a transport entity determines that a particular 
connection is released it shall place the reference which it 
has allocated to the connection in a frozen state according 
to the procedures of the class. While frozen, the reference 
shall not be re-used. 

NOTE - The frozen reference procedure is necessary because 
retransmission or misordering can cause TPDUs bearing a 
reference to arrive at an entity after it has released the connection 
for which it allocated the reference. Retransmission, for example, 
can arise when the class includes either resynchranization (see 
6.14) or retransmission on time-out (see 6.1 9). 

6.18.2.1 Procedure for classes and 2 

This International Standard does not specify frozen 
reference procedures for classes and 2. « 
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NOTE - For consistency with other classes, references may be 
frozen as a local matter. 



6.18.2.2 Procedure for classes 1 and 3 

The frozen reference procedure is used except in the 
following cases (see note 1 ): 

a) wfien the transport antity receives a DC TPDU in 
response to a DR TPDli which it has sent (see note 2); 

b) When the transport entity sends a DR or ER TPDU in 
response to a CR TPDU wnich it has received (see note 
3); 

c) when the transport entity has considered the 
connection to be released after the expiration of the 
TWR tinner (see note 4); 

d) when the transport entity receives a DR or ER TPDU 
in response to a CR TPDU which it has sent; 

e) when the reference is zero. 

The period of time for which the rafsrence remains frozen 
shall be greater than the TWR time. 

NOTES 

1 However, even in these cases, for consistency freezing the 
reference may be done as a local decision. 

2 When the DC TPDU is received it is certain that the other 
transport entity considers the connection release d. 

3 When the DR or ER TPDU is sent the peer transport entity has 
not been informed of any reference assignment ard fius cannot 
possibly make use of a reference (this includes the cas€ where a 
CC TPDU was sent, but was lost). ' ' 

4 In c) the transport entity has already effectively frozsn the 
reference for an adequate period. 

6.1 8.2.3 Procedure for class 4 

The frozen reference procedure shall be used in class 4. 
The period for which the reference remains frozen shall be 



6.19 Retranshiission on time-out 



6.19.1 Purpose 

The procedure is used in class 4 to cope with unsignalled 
loss of TPDUs by the NS provider. 



6.19.2 TPDUs used 

The procedure uses the following TPDUs: 
CR. CC, DR, DT, ED, AK TPDUs. 



6.19.3 Procedure 

The procedure is specified in the procedures for class 4 
[see 12.2.1.2 j) and 12.2.1.3 g)]. 

6.20 Resequencing 

6.20.1 Purpose 

The resequencing procedure is used in class 4 to cope with 
misordering of TPDUs by the network service provider. 

6.20.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) DTTPDU 

- TPDU-NR; 

b) ED TPDU 

- ED TPDU-NR. 

6.20.3 Procedure 

The procedure is specified in the procedures for class 4 
(see 12.2.3.5). 

6.21 Inactivity control 

6.21.1 Purpose 

The inactivity control procedure is used in class 4 to cope 
with unsignalled termination of a network connection when 
using CONS and the failure of a remote transport entity 
when using CONS or CLNS. 

6.21.2 Procedure 

The procedure is specified in the procedures for class 4 
(see 12.2.3.3). 

6.22 Treatment of protocol errors 

6.22.1 Treatment of protocol errors when operating 
over CONS 

6.22.1.1 Purpose 

The procedure for treatment of protocol errors is used in all 
classes to deal with invalid TPDUs. 

6.22.1.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) ERTPDU 

- reject cause; 
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-- invalid TPDU; 

b) DRTPDU 

- reason code. 



6.22.1.3 



Procedure 



A transport entity that receives a TPDU that can be 
associated to a transport connection and is invalid or 
constitutes a protocol error (see 3.2.16 and 3.2.17) shall 
take one of the following actions so as not to jeopardize any 
other transport connections not assigned to that network 
connection: 

a) transnnit an ER TPDU; 

b) reset or close the network connection; or 

c) invoke the release procedures appropriate to the 
class. 

Under certain circumstances it is also possible to discard 
the TPDU. 

If an ER TPDU is sent in class it shall contain the octets of 
the invalid TPDU up to and including the octet where the 
error was detected (see notes 3, 4 and 5). 

If the TPDU cannot be associated with a particular transport 
connection the transport entity shall follow the procedures in 
6.9. 

NOTES 

1 In general, no further action is specified for the receiver of the 
ER TPDU but it is rGcommendecl that it initiates the release 
procedure appropriate to frie class. If the ER TPDU has been 
received as an answer to a CR TPDU then the connection is 
regarded as released (see 6.6). 

2 Car© should be taken by a transport entity receiving several 
invalid TPDUs or ER TPDUs to avoid looping if the error is 
generated repeatedly. 

3 If the invalid received TPDU is greater than the selected 
maximum TPDU size-inclusion in the invalid TPDU parameter of 
the ER TPDU may not be possible. 

4 It is recommended that the sender of the ER TPDU starts an 
optional timer TS2 to ensure the release of the connection. If the 
timer expires, the transport entity shall initiate the release 
procedures appropriate to the class. The timer should be stopped 
when a DR TPDU or an N-DISCONNECT indication is received. 

5 In classes other than 0, it is recommended that the invalid 
TPDU be also included in the ER TPDU. 



6.22.2 Treatment of protocol errors when operating 
over CLNS 



6.22.2.1 Purpose 

The procedure for treatnnent of protocol errors is used to 
deal with invalid TPDUs. 



6.22.2.2 TPDUs and parameters used 

The procedure uses the following TPDUs and parameters: 

a) ER TPDU; 

- reject cause; 

- invalid TPDU; 

b) DR TPDU; 

- reason. 



6.22.2.3 



Procedure 



Invalid TPDUs and protocol errors shall be ignored (no 
action and TPDU discarded, or responded to with an ER 
TPDU), except for the following case: a CC TPDU is 
received in which the class field does not specify class 4 
and a previously sent CR TPDU has not yet been 
acknowledged. In this case, the transport connection shall 
be terminated (see 6.7). 

NOTE - It is recommended that the sender of the ER TPDU starts 
an optional timer TS2 to ensure the release of the connection. If 
the timer expires, the transport entity shall initiate the release 
procedure appropriate to class 4. The timer should be stopped 
when a DR TPDU is received. 

6.23 Splitting and recombrning when operating over 
CONS 

6.23.1 Purpose 

This procedure is used only in class 4 to allow a transport 
connection to make use of multiple network connections to 
provide additional resilience against network failure, to 
increase throughput, or for other reasons. 

6.23.2 Procedure 

When this procedure is being used, a transport connection 
may be assigned (see 6.1) to multiple network connections 
(see note 1). TPDUs for the connection may be sent over 
any such network connection. 

If the use of class 4 is not accepted by the remote transport 
entity following the negotiation rules, then no network 
connection except that over which the CR TPDU was cent 
may have the transport connection assigned to it. 
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NOTES 

1 The resequencing function of class 4 (see 6.20) is used to 
ensure that TPDUs are processed in frie correct sequence. 

2 Either transport entity may assign the connection to further 
network connections of which it is the owner at any time during the 
life of the transport connection, provided the following constraints 
are respected: 

- the initiator does not start splitting before having received 
the CC TPDU; 

- as soon as a new assignment is carried out it is 
recommended to send a TPDU on this network connection in 
order to make the remote entity aware of this assignment. 

3 A transport entity performing splitting should ensure that TPDUs 
are sent at intervals on each supporting network connection, for 



example, by sending successive TPDUs on succ&sslve network 
connections, where the set of network connections is used 
cyclically. 

When splitting is used the inactivity control procedure defines in 
12.2.3.3 will not normally detect unsignalled network connection 
failure. Any method of monitoring network connections to detect 
such failure is a local matter. 



7 Protocol classes 

Table 6 gives an overview of which elennerits of procedure 
are included in each class. In certain cases, the elennents 
of procedure within different classes are not identical and, 
for this reason, table 6 cannot be considered as part of the 
definitive specification of the protocol. 
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Table 6 - 


Allocation of elements of procedures within c 


asses 








Protocol mechanism 


Cross- 
reference 


Variant or 
Option 





1 


2 


3 


4 
CONS- 


4 
CLNS 


Assignment to network connection 


6.1.1 




x 


X 


X 


X 


X 




TPDU transfer 


6.2 




x 


X 


X 


X 


X 


X 


Segmenting and reassembling 


6.3 




X 


X 


X 


X 


X 


X 


Concatenation and separation 


6.4 






X 


X 


X 


X 


X 


Connection establishment 


6.5 




X 


X 


X 


X 


X 


X 


Connection refusal 


6.6 




X 


X 


X 


X 


X 


X 


Normal release 


6.7 


Implicit 
Explicit 


X 


X 


X 


X 


X 


X 


Error release 


6.8 




X 




X 








Association of TPDUs witfi 
transport connection 


6.9 




X 


X 


X 


X 


X 


X 


TPDU numbering 


6.10 


Normal 
Extended 




X 


m(1) 

0(1) 


m 




m 




m 




Expedited data transfer 


6.11 


Network Normal 
Network Expedited 




m 
ao 


x(1) 


X 


X 


X 


Reassignment after failure 


6.12 






X 




X 


(3) 




Retention and acknowledgement 
of TPDUs 


6.13 


Confirmation of 

receipt 

AK 

Use of selective 

acknowledgement 

Use of request 

acknowledgement 




ao 
m 

0(4) 




X 

o 


X 






X 






Resynchronization 


6.14 






X 




X 


(3) 




Multiplexing and demultiplexing 


6.15 








x(2) 


X 


X 




Explicit flow control (with) 
Explicit flow control (without) 


6.16 




X 


X 


m 




X 


X 


X 


Checksum (use of) 
Checksum (non-use of) 


6.17 




X 


X 


X 


X 


m 




m 




Frozen references 


6.18 






X 




X 


X 


X 


Retransmission on time-out 


6.19 












X 


X 


Resequencinq 


6.20 












X 


X 


Inactivity control 


6.21 












X 


X 


Treatment of protocol errors 


6.22 




X 


X 


X 


X 


X 


X 


Splitting and recombining 


6.23 












X 





Key to Table 6: 



Procedure always included in class 



Not applicable 



Negotiable procedure whose implementation in equipment is mandatory 



Negotiable procedure whose implementation in equipment is optional 



ao 



Negotiable procedure whose implementation in equipment is optional and where use depends of 
availability within the network se'-vice 



111 



Not applicable in class 2 when non-use of explicit flow control is selected 



(2) 



fvlultiplexing may lead to degradation of the quality of service if the non-use of explicit flow control has 
been selected 



This function is provided in class 4 using procedures other than those used in the cross-reference 
This option is not applicable in class 1, when the confirmation of receipt variant has been selected 



_(3I 



iil 
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8 Specification for class 0: Simple class 

8.1 Functions of class 

Class is designed to have minimum functionality, it 
provides only the functions needed for connection 
establishment with negotiation, data transfer with 
segmenting and protocol error reporting. 

C'gss provides transport connections with flow control 
based on the network service provided flow control, and 
disconnection based on the network service disconnection. 

8.2 Procedures for class • 

8.2.1 Procedures applicable at all times 

The transport entities shall use the following procedures: 

a) TPDU transfer (see 6.2); 

b) association of TPDUs with transport connections 
(see 6.9); 

c) treatment of protocol errors (see 6.22); 

d) error release (see 6.8). 

8.2.2 Connection establishment 

The transport entities shall use the following procedures: 

a) assignment to network connection (see 6.1.1); then 

b) connection establishment (see 6.5) and, if 
appropriate, connection refusal (see 6.6); 

subject to the following constraints: 

1) the CR and CC TPDUs shall contain no parameter 
fields in the variable part of the header other than those 
for TSAP-ID, maximum TPDU size, and preferred 
maximum TPDU size; 

2) the CR and CC TPDUs shall not contain a data field. 

8.2.3 Data transfer 

The transport entities shall use the segmenting and 
reassembling procedure (see 6.3). 

8.2.4 Release 

The transport entities shall use the implicit variant of the 
normal release procedure (see 6.7.1.4). 

NOTE - The lifetime of the transport connection is directly 
correlated with the lifetime of the network connection. 



9 Specification for class 1: Basic error 
recovery class 

9.1 Functions of class 1 

Class 1 provides transport connections with flow control 
based on the network service provided flow control, error 
recovery, expedited data transfer, disconnection, and also 
the ability to support consecutive transport connections on a 
network connection. 

This class provides the functionality of class plus the 
ability to recover after a failure signalled by the Network 
Service, without involving the TS-user. 

9.2 Procedures for class 1 

9.2.1 Procedures applicable at all times 

The transport entities shall use the following procedures: 

a) TPDU transfer (see 6.2); 

b) association of TPDU with transport connections (see 
6.9); 

c) treatment of protocol errors (see 6.22); 

d) reassignment after failure (see 6.1 2); 

e) resynchronization (see 6.14), or reassignment after 
failure (see 6.12) together with resynchronization (see 
6.14); 

f) concatenation and separation (see 6.4); 

g) retention and acknowledgement of TPDUs (see 
6.13); the variant used, AK or confirmation of receipt, 
shall be as selected during connection establishment 
(see the notes); 

h) frozen references (see 6.18). 
NOTES 

1 The negotiation of the variant of retention and 
acknowledgement of TPDUs procedure to be used over the 
transport connection has been designed such that if the initiator 
proposes the use of the AK variant (i.e. the mandatory 
implementation option), the responder has to accept use of this 
option and if the initiator proposes use of the confimnation of receipt 
variant the responder is entitles to select use of the AK variant. 

2 The AK variant makes use of AK TPDUs to release copies of 
retained DT TPDUs. The CDT parameter of AK TPDUs in class 1 
is not significant, and is set to 1111. 

3 The confirmation of receipt variant is restricted to this class and 
its use depends on the availability of the network layer receipt 
confinnation service', and the expected cost reduction. 



36 



IS 13919; 1994 

I SO/I EC 8073 : 1992 



9.2.2 Connection establishment 

The transport entities shall use the following procedures: 

a) assignment to network connection (see 6.1 .1 ); then 

b) connection establishment (see 6,5) and, if 
appropriate, connection refusal (see 6.6). 



9.2.3 



9.2.3.1 



Data transfer 



General 



The sending transport entity shall use the following 
procedures: 

a) segmenting (see 6.3); then 

b) the normal format variant of DT TPDU numbering 
(see 6.10). 

The receiving transport entity shall use the following 
procedures: 

1 ) the normal format variant of DT TPDU numbering 
(see 6.10); then 

2) reassembling (see 6.3). 

NOTE - The decision to Issue an N-RESET request in order to 
force the remote entity to carry out the resynchronization (see 6.14) 
may be made on a local basis. 



9.2.3.2 Expedited data 

The transport entities shall use either the network normal 
data or the network expedited variants of the expedited data 
transfer procedure (see 6.1 1) if their use has been selected 
during connection establishment (see note 1). 

The sending transport entity shall not allocate the same 
EDTPDU-NR to successive ED TPDUs (see notes 2 and 3). 

When acknowledging an ED TPDU by sending an EA TPDU 
the transport entity shall put into the YR-EDTU-NR 
parameter of the EA TPDU the value received in the ED- 
TPDU-NR parameter of the ED TPDU. 

NOTES 

1 The negotiation of the variant of expedited data transfer 
procedure to be used over the transport connection has been 
designed such that if the initiator proposes the use of the network 
nomnal data variant (i.e. the mandatory implementation option), the 
responder has to accept use of this option and if the initiator 
proposes use of the network expedited variant, the responder is 
entitled to select use of the network nomial data variant. 

2 This numbering enables the receiving transport entity to discard 
repeated ED TPDUs when resynchronization {see 6.14) has taken 
place. 



3 No other significance is attached to the ED-TPDU-NR 
parameter. It is recommended, but not essential, that the values 
used be consecutive modulo 128. 

4 The use of RJ TPDUs during resynchronization (see 6.14) can 
lead to retransmission. Thus, the receipt of a duplicate ED TPDU is 
possible. Such an ED TPDU is discarded. 



9.2.4 



Release 



The transport entities shall use the explicit variant of the 
release procedure (see 6.7.1.5). 



10 Specification for class 2: Multiplexing 
class 

10.1 Functions of class 2 

Class 2 provides transport connections with or without 
individual flow control; no e'rror detection or error recovery is 
provided. 

If the network connection resets or disconnects, the 
transport connection is terminated without the transport 
release procedure and the TS-user is informed. 

When explicit flow control is used, a credit mechanism is 
defined allowing the receiver to inform the sender of the 
exact amount of data he is willing to receive and that the 
expedited data transfer is available. 

10.2 Procedures for class 2 

10.2.1 Procedures applicable at all times 

The transport entities shall use the following procedures 

a) association of TPDUs with transport connection (see 
6.9); 

b) TPDU transfer (see 6.2); 

c) treatment of protocol errors (see 6.22.1); 

d) concatenation and separation (see 6.4); 

e) error release (see 6.8). 

Additionally the transport entities may use the following 
procedures: 

f) multiplexing and demultiplexing (see 6.15). 

10.2.2 Connection establishment 

The transport entities may use the following procedures: 
a) assignment to network connection (see 6.1.1)» then 
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b) connection establishment (see 6.5) and, \i applicable, 
connection refusal (see 6.6). 

10.2.3 Data transfer when non-use of explicit flow 
control has been selected 

If this option has been selected as a result of the connection 
establishment, the transport entities shall us3 the 
segmenting procedure (sea 6.3). 

The TPDU-NR field of DT TPDUs is not significant and may 
take any value. 

NOTE - Expedited data transfer is not applicable (see 6.5). 

10.2.4 Data transfer when use of explicit flow control 
has been selected 

10.2.4.1 General 

The sending transport entity shall use the following 
procedures: 

a) segmenting (see 6.3): then 

b) DT TPDU numbering (see 6.10). 

The receiving transport entity shall use the following 
procedures: 

1) DT TPDU nLimbering (sRe 6. TO); if a DT TPDU is 
received which is out of sequence it f;hail be treated as a 
protocol error; then 

2) rea.s.sembling (see 6.3). 

The variant of the DT TPDU numbering which is used by 
both transport entitiss shall be that which was agreed at 
connection establishment. 



b) if an AK TPDU has previously been sent the value of 
the YR-TU-NR parameter shall not be lower than that in 
the previously sent AK TPDU; 

c) the sum of the YR-TU-NR and CDT fields shall not 
be less than the upper window sdge allocated to the 
remote entity (see note 1). 

A transport entity which receives an AK TPDU shall 
■consider the YR-TU-NR field as its new lower window edge, 
and the sum of YR-TU-NR and CDT as its new upper 
window edge. If either of these have been reduced or if the 
lower window edge has become more than one greater than 
the T'PDU-NR of the last transmitted DT TPDU, this shall be 
treated as a protocol error (see 6.22.1). 

A transport entity shall not send a DT TPDU with a TPDU- 
NR outside of the transmit window (see notes 2 and 3). 

NOTES 

1 This means that credit reduction is not applicable. 

2 This means that a transport entity is required to slop sending if 
the TPDU-NR field of the next DT TPDU which would be sent would 
be the upper window edge, Sending ot DT TPDU may be resumed 
if an AK TPDU is received which increases the upper window edge. 

3 The rate at which a transport entity progresses the upper 
window edge allocated to its peer entity constrains the throughput 
attainable on the transport connection. 

10.2.4.3 Expedited data 

The transport entities shall follow the network normal data 
variant of the expedited data transfer procedure in 6.1 1.1 if 
its use has been agreed during connection establishment. 
ED and EA TPDUs are not subject to the flow control 
procedures in 10.2.4.2. The ED-TPDU-NR and YR-ETDU- 
NR fields of ED and EA TPDUs respectively are not 
significant and may take any value. 



10.2.4.2 



h low control 



10.2.5 Release 



The transport entities shall send an initial r^redit (which may 
be zero) in the CDT field of the CR or CC TPDU. This credit 
represents the initial vakie of the upper window edge 
allocated to the peer entity. 

The transport entity that receives the CR or the CC TPDU 
shall consider its lower window edge as zero, and its upper 
window edge as the value of the CDT field in the received 
TPDU. 



The transport entities shall use the explicit variant of the 
release procedure in 6.7.1 . 



11 Specification for class 3: Error recovery 
and multiplexing class 

11.1 Functions of class 3 



In order to authorize the transmission of DT TPDUs, by its 
peer, a transport entity may transmit an AK TPDU at any 
time, subject to the following constraints: 

a) the YR-TU-NR parameter shall be at most one 
greater than the TPDU-NR field of the last received DT 
TPDU or shall be zero if no DT TPDU has been 
received; 



Class 3 provides the functionality of class 2 (with use of 
explicit flow control) plus the ability to recover after a failure 
signalled by the Network Layer without involving the TS- 
user. 

The mechanisms used to achieve this functionality also 
allow the implementation of more flexible flow control. 
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1 1 .2 Procedures for class 3 

11 .2.1 Procedures applicable at all times 

The transport entities sliall use the following procedures: 

a) association of TPDUs with transport connections 
(see 6.9); 

b) TPDU transfer (see 6.2) and retention and 
acknowledgement of TPDUs (AK variant only) (see 
6.13); 

c) treatment of protocol errors (see 6.22,1 ); 

d) concatenation and separation (see 6.4); 

e) reassignment after failure (see 6.12), together with 
resynchronization (see 6.14); 

f) frozen references (see 6. 1 8). 

Additionally, the transport entities may use the following 
procedure: 

g) multiplexing and demultiplexing (see 6.15). 

1 1 .2.2 Connection establishment 

The transport entities shall use the following procedures: 

a) assignment to network connections (see 6. 1 . 1 ); then 

b) connection establishment (see 6.5) and, if 
appropriate, connection refusal {see 6.6). 

11.2.3 Data transfer 

11.2.3.1 General 

The sending transport entity shall use the following 
procedures: 

a) segmenting (see 6.3); then 

b) DT TPDU numbering (see 6.10); after receipt of an 
RJ TPDU (see 11.2.3.2) the next DT TPDU to be sent 
may have a value which is not the previous value, of 
TPDU-NR plus one. 

The receiving transport entity shall use the following 
procedures: 

1) DT TPDU numbering (see 6.10); the TPDU-NR field 
of each received DT TPDU shall be treated as a protocol 
error if it exceeds the greatest value rec )ived in a 
previous DT TPDU by more than one (see the note); 
then 



2) Reassembling (see 6.3); duplicated TPDUs shall be 
eliminated before reassen^ling is performed. 

NOTE - The use of RJ TPDUs (see 11.2.3.2) can lead to 
retransmission and reduction of credit. Thus the receipt of a DT 
TPDU which is a duplicate, or which Is greater than or equal to the 
upper window edge allocated to the peer entity, is possible and is 
therefore not treated as a protocol error. 

11.2.3.2 Use of an RJ TPDU 

A transport entity may send an RJ TPDU at any time in 
order to invite retransmission or to reduce the upper window 
edge allocated to the peer entity (see note 1). 

When an RJ TPDU is sent, the following constraints shall be 
respected: 

a) the YR-TU-NR parameter shall be at most one 
greater than the greatest value received in a previous 
DT TPDU, or shall be zero if no DT TPDU has yet been 
received (see note 2); 

b) if an AK or RJ TPDU has been sent previously the 
YR-TU-NR parameter shall not be lower than that in the 
AK or RJ TPDU sent previously. 

When a transport entity receives an RJ TPDU (see note 3): 

c) the next DT TPDU to be transmitted, or 
retransmitted, shall be that for which the value of the 
TPDU-NR parameter is equal to the value of the YR-TU- 
NR parameter of the RJ TPDU; 

d) the sum of the values of the YR-TU-NR and CDT 
parameters of the RJ TPDU becomes the new upper 
window edge (see note 4). 

NOTES 

1 An RJ TPDU can also be sent as part of the resynchronization 
(see 6.14) and reassignment after failure (see 6.12) procedures. 

2 It is recommended that the YR-TU-NR parameter be equal to 
the TPDU-NR parameter of the next expected DT TPDU, 

3 These rules are a subset of those specified for the case when 
an RJ TPDU is received during resynchronization (see 6.14) and 
reassignment after failure (see 6. 12). 

4 This means that an flj TPDU can be used to reduce the upper 
window edge ailocatec to the peer entity (credit reduction). 

11.2.3.3 Flow control 

The procedures shall be as defined in 10.2.4.2, except that 

a) a credit reduction may lead to the reception of a DT 
TPDU with a TPDU-NR parameter whose value is not, 
but would have been less than the upper window edge 
allocated to the remote entity prior to the credit 
reduction. This shall not be treated as a protocol error; 
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b) receipt of an AK 1 PDU which sels the lower window 
edge more than one greater than the TPDU-NR of the 
last transmitted DT TPDU shall not be treated as a 
protocol error, provided that all acknowledged DT 
TPDUs have been previously transmitted (see notes 1 
and 2). 

NOTES 

1 This can only occur during retransmission following receipt of an 
RJ TPDU. 

2 The transport anlity may either uontiiiua retransmission as 
before or retransmit only thoDO DT TPDU.<!, not acknowledged by 
ths AK TPDU. in either cass, copies of the acknowledged DT 
TPDUs need not ba retained 



11.2.3.4 Expedited data 

The transport entities shall follow the network normal data 
variant of the expedited data transfer procedure in 6.11,1 if 
its use has been agreed during connection establishment. 

The sending transport entity shall not allocate the same ED- 
TPDLI-NR to successive ED TPDUs. 

The receiving tr.^nspor< entity shall transmit an EA TPDU 
with the same vasjjs in its YR-EDTU-NR parameter. If, and 
only if, this number is different from that of the ED TPDU 
perceived previously,, shall it generate a T-EXPEDITED 
DATA indication to convey the data to the TS-user (see note 



NOTl 



1 No other siarriiicance is attached to the ED-TPDU-NB 
paranister. I! is rscommended, but not essential that the values be 
consecutivs moduio 2", wriere n is the number of bits of the 
param$!er. 

2 This Drocedure snsurss that the TS-user does not receive data 
corresponding to the same ED TPDU more than once. 

11.2.4 Release 

The transport entities shall use the explicit variant of the 
release procedure in 6.7.1. 



12 Specification for class 4: Error detection 
and recovery class 

12.1 Functions of class 4 

12.1.1 Functions of class 4 when operating over 
CONS 

Class 4 provides the functionality of class 3, plus the ability 
to detect and recover from lost, duplicated, or out of 
sequence TPDUs without involving the TS-user. 



This detection of errors is made by extended use of the DT 
TPDU numbering of class 2 and class 3, by time-out 
mechanisms, and by additional procedures. 

Class 4 detects signalled and unsignalled network failures 
(i.e. resets or disconnects or inactivity) and recovers from 
these failures by using time-out mechanisms. 

This class detects and rt-covers from damaged TPDUs by 
using a checksum mechanism. The checksum mechanism 
shall be available but its use or its non-use is subject to 
negotiation. 

This class also provides additional resilience against 
network failure and increased throughput capability by 
allowing a transport connection to make use of multiple 
network connections. 



12.1.2 
CLNS 



Functions of class 4 when operating over 



Class 4 provides flow control between peer transport 
entities, the capability to detect and recover from errors 
which occur as a result of a low grade service available from 
the network service provider and resilience from failure of 
the peer entity - the kind of errors to be detected include: 
TPDU loss, TPDU delivery out of sequence, TPDU 
duplication and TPDU corruption - these errors may affect 
control TPDUs as well as data TPDUs. 

The detection of errors is made by use of TPDU numbering 
on DT, AK, ED and EA TPDUs, by time-out mechanisms 
and additional procedures such as the use of a checksum 
mechanism. The use of the checksum mechanism shall be 
available but its use or its non-use is subject to negotiation. 

12.2 Procedures for class 4 



12.2.1 Procedures available at all times 

12.2.1.1 Timers used at all times 

This sub-clause defines timers that apply at all times in 
class 4. These timers are listed in table 7. 

This International Standard does not define specific values 
for the timers, and the derivations described in this sub- 
clause are not mandatory. The values should be chosen so 
that the required quality of service can be provided, given 
the known characteristics of the network. 

Timers that apply only to specific procedures are defined 
under the appropriate procedure. 

12.2.1.1.1 NSDU lifetime (Mlr, Mri) 

The Network Layer is assumed to provide, as an aspect of 
its grade of service, for a bound on the maximum lifetime of 
NSDUs in the network. This value may be different in each 
direction of transfer through a network between two 
transport entities. The values, for both direfctions of transfer, 
are assumed to be known by the transport entities. The 
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maximum NSDU lifetime local-to-/emote (Mifi) is the 
maximum time which may elapse between the transmission 
of an NSDU from the local transport entity to the networl< 
and receipt of any copy of the NSDU from the network at 
the remote transport entity. The maximum NSDU lifetime 
remote-to-local (MflJ is the maximum time which may 
eiapse between the transmission of an NSDU from the 
remote transport entity to the network and receipt of any 
copy of the NSDU from the network at the locai transport 
entity. 

12.2.1.1.2 Expected maximum transit delay (£^lr, Epi) 

The Network Layer is assumed to provide, as an aspect of 
its grade of service, an expected maximum transit delay for 
NSDUs in the network. This value may be different in each 
direction of transfer through a network between two 
transport entities. The values, for both directions of transfer, 
are assumed to be know.n by the transport entities. The 
expected maximum transit delay local -to-remote (E^^) is the 
maximum delay suffered by all but a small proportion of 
NSDUs transferred through the network from the local 
transport entity to the remote transport entity. The expected 
maximum transit delay remote-to-local (E^l) is the 
maximum delay suffered by all but a small proportion of 
NSDUs transferred through the network from the remote' 
transport entity to the local transport entity. 

1 2.2.1 .1 .3 Acknowledgement time (Api, AJ 

Any transport entity is assumed to provide a bound for the 
maximum time which can elapse between its receipt of a 
TPDU from the Network Layer and its transmission of the 
corresponding response. This value is referred to as A^. 
The corresponding time given by the remote transport entity 
is referred to as Ap/. 

12.2.1.1.4 Local retransmission time (TJ) 

The local transport entity is assumed to m.aintain a bound 
on the time it will wait for an acknowledgement before 
retransm.itting the TPDU. Its value is given by 

Tl = Ei^p,+ Epi+ Apt+x 

where 

Eiff is the expected maximum transit delay local-to- 
remote; 

EflL is the expected maximum transit delay remote-to- 
local; 

/Afl is the remote acknowledgement time; 

X is the local processing time for a TPDU. 

NOTE - During connection establishment the value of Ap is not 
known. In this case a suitable bound for Tl may be established 
either by estimating (or having a priori knowledge of) Afj or by 
applying a suitable algorithm to the transport connection 
establishment delay QOS parameter. 



12.2.1.1.5 Persistence time (fl) 

The local transport entity is assumed to provide a bound for 
the maximum time for which it may continue to retransmit a 
TPDU requiring positive acknowledgement and which is not 
outside the current transmit window, even after credit 
reduction, This value is referred to as R. 

The value is clearly related to the time elapsed between 
retransmission, Tl, and the maximum number of 
transmissions, N. It is not less than Tl * {N- 1] + x, where x 
is a small quantity to allow for additional internal delays, the 
granularity of the mechanism used to implement T1, etc. 
Because f? is a bound, the exact value of x is unirnportant 
as long as it is bounded and the value of a bound is known. 

12.2.1.1-6 Time bound of references and sequence 

numbers (L) 

A bound for the maximum time between the decision to 
transmit a TPDU and the receipt of any acknowledgement 
relating to it (L) is given by; 

L = Mif, + Mri_ + R+ Af, 

where 

M/fl is the NSDU lifetime local-to-remote; 

Mpfi is the NSDU lifetime remote-to-local; 

R is the persistence time; 

Afj is the remote acknowledgement time. 

It is necessary to wait for a period of time before reusing 
any reference or sequence number in order to avoid 
confusion when a TPDU referring to it is duplicated or 
delayed. 

The period of time during which the sequence numbers for 
DT TPDUs should be frozen is the period L, starting from 
the time when the sequence number has fallen below the 
lower window edge. 

NOTES 

1 In practice, the value of L may be too large. It may also be only 
a statistical figure at a certain confidence level. A smaller value 
may therefore be used where this still allows the required quality of 
sen/ice to be provided. 

2 Tfie relationships between times discussed above are illustrated 
in figures 3 and 4. 

12.2.1.1.7 Inactivity timer (4, y 

Any transport entity is assumed to provide a lower bound for 
the time which can elapse without receipt of a TPDU before 
it will initiate the release procedure to terminate the 
transport connection. This value is referred to as 4 The 
corresponding time given by the remote transpoH entity is 
referred to as Ip^. 
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Figure 3 - Interrelationship of times for the average case in class 4 




R = Ti*(N-1) + x 



L = Mlr + Mrl + R + a 



Figure 4 - Interrelationship of times for maximum delay in class 4 
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Table 7 - Time parameters related to the operation of class 4 



Symbol 


Name 


Definition 


Wt^H 


NSDU lifetime local-to- 
remote 


A time bound for the maximum time which may elapse between the 
transmission of an NDSU by a local transport entity and the receipt of any copy 
of it by a remote peer entity. 


Mrl 


NSDU lifetime remote-to- 
local 


A time bound for the maximum time which may elapse between the 
transmission of an NSDU from a remote transport entity and the receipt of any 
copy of it by the local peer entity. 


Elr 


Expected maximum transit 
delay local-to-remote 


A time bound for the maximum delay suffered by all but a small proportion of 
NSDUs transferred from the local transport entity to a remote peer entity. 


Erl 


Expected maximum transit 
delay remote-to-local 


A time bound for the maximum delay suffered by all but a small proportion of 
NSDUs transferred from a remote peer entity to the local transport entity. 


Al 


Local acknowledgement 
time 


A time bound for the maximum time which can elapse between the receipt of a 
TPDU by the local transport entity from the network layer and the transmission 
of the corresponding acknowledgement. 


Ah 


Remote acknowledgement 
time 


As Ai, but for the remote entity. 


77 


Local retransmission time 


A time bound for the maximum time the local transport entity will wait for 
acknowledgement before retransmitting a TPDU. 


R 


Persistence time 


A time bound for the maximum time the local transport entity will continue to 
transmit a TPDU that requires acknowledgement. 


N 


Maximum number of 
transmissions 


A time bound for the maximum number of times which the local transport entity 
will continue to transmit a TPDU that requires acknowledgement. 


L 


Time bound on references 
and sequence numbers 


A time bound for the maximum time between the transmission of a TPDU and 
the receipt of any acknowledgement relating to it. 


k 


Local inactivity lime 


A lower bound for the time after which the local transport entity will, if It does 
not receive a TPDU, initiate the release procedure to terminate the transport 
connection. 

NOTE - This parameter is required for protection against unsignalled failures. 


Ir 


Remote inactivity time 


A lower bound for the time after which the remote transport entity will, if it does 
not receive a TPDU, initiate the release procedure to terminate the transport 
connection. 

NOTE - This parameter is required for protection ag^st unsignalled failures. 


W 


Window time 


A time bound for the maximum time a transport entity will wait before 
retransmitting up-to-date window information. 



12.2.1.2 General procedures when operating over 
CONS 

The transport entity shall use the following procedures: 

a) TPDU transfer (see 6.2); 

b) association of TPDUs with transport connections 
(see 6.9.1); 

c) treatment of protocol errors (see 6.22.1); 

d) checksum (see 6.17); 



e) splitting and recombining (see 6.23); 

f) multiplexing and demultiplexing (see 6.15); 

g) retention and acknowledgement of TPDUs (see 
6.13); 

h) frozen references (see 6.18); 

j) retransmission procedures; when a transport entity 
has some outstanding TPDUs that require 
acknowledgement, it will check that no T1 interval 
elapses without the arrival of a TPDU that acknowledges 
at least one of the outstanding TPDUs. If the timer 
expires, the first TPDU is retransmitted and the timer is 
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restarted except if the TPDU to be retransmitted is a DT 
TPDU and is outside the transmit window due to credit 
reduction. Retransmission of a TPDU is subject to the 
availability of a network connection. If no networl< 
connection is available, and the retransmission timer 
runs out, then the retransmission counter may be 
incremented without sending the TPDU subject to the 
retransmission procedure. After /V transmissions (i.e. N - 
1 retransmissions) it is assumed that useful two-way 
communication is no longer possible and the release 
procedure is used, and the TS-user is informed: 

NOTES 

1 This procedure may be implemented by different msans. 
For example: 

a) one interval is associated with each TPDU, If the timer 
expires the associated TPDU will be retransmitted and the 
timer TJ will be restarted for all subsequent TPDUs; or 

b) one interval is associated with each transport 
connection: 

1)' if the transport entity transmits a TPDU requiring 
acltnowledgement, it starts timer T1; 

2) if (he transport entity receives a TPDU that 
acknowledges one of the TPDUs to be acknowledged, it 
restarts timer T1 unless the received TPDU is an AK 
which explicitly closes the transmit window; 

3) if the transport entity receives a TPDU that 
acknowledges the last TPDU to be acknowledged, it 
slops timer T1. 

For a decision whether the retransmission timer Tl is 
maintained on a per TPDU or on a per transport connection 
basis, throughput considerations have to be taken into account. 

2 For DT TPDUs it is a local choice to retransmit either only 
the first DT TPDU or all TPDUs waiting for an 
acknowledgement up to the upper window edge. 

3 It is recommended that after N transmissions, tti© transport 
entity waits Tl + W + Mpi in order to provide a higher 
possibility of receiving an acknowledgement before entering the 
release phase. For other TPDU types which may be 
retransmitted, it is recommended that after N transmissions the 
transport entity waits T1 + Mf^i in order to provide a greater 
possibility of receiving the expected reply. 

4 If use of selective acknowlec^ement has been negotiated, a 
selective acknowledgement implicitly identifies DT TPDUs not 
received. Since such a DT TPDU could be a lost dT TPDU, or 
simply a delayed DT TPDU, it is a local matter whether DT 
TPDUs not acknowledged in a selective acknowledgement 
should be retransmitted immediately. 

k) concatenation and separation {see 6.4). 
12.2.1.3 Genera! procedures when operating over CLNS 
The transport entity shall use the following procedures: 

a) TPDU transfer (see 6.2); 



b) association of TPDUs with transport connections 
(see 6.9.1); 

c) treatment of protocol errors (see 6.22.2); 

d) checksum (see 6.17); 

e) retention and acknowledgment of TPDUs (see 6.13); 

f) frozen references (see 6.18); 

g) retransmission procedures; when a transport entity 
has some outstanding TPDUs that require 
acknowledgment, it will check that no Tl interval elapses 
without the arrival of a TPDU that acknowledges at least 
one of the outstanding TPDUs. 

If the timer expires, except if the TPDU to be 
retransmitted is a DT TPDU and it is outside the 
transmit window due to credit reduction, the first TPDU 
is retransmitted and the timer is restarted. After N 
transmissions (i.e. N- 1 retransmissions) it is assumed 
that useful two-way communication is no longer possible 
and the release procedure is used, and the TS-user is 
informed; 

NOTES 

1 This procedure may be implemented by different means, 
For example: 

a) one interval is associated with each TPDU. If the timer 
expires ttie associated TPDU will be transmitted and ttie 
timer Tl will be restarted for all subsequent TPDUs; or 

b) one interval is associated with each transport 
connection: 

1) if the transport entity transmits a TPDU requiring 
acknowledgment, it starts timer TT, 

2) if the transport entity receives a TPDU that 
acknowledges one of the TPDUs to be acknowledged, 
it restarts timer Tl unless the received TPDU is an AK 
which explicitly closes tfie transmit window; 

3) if the transport entity receives a TPDU that 
acknowledges the last TPDU to be acknowledged, it 
stops timer Tl. 

For a decision whether the retransmission timer Tl is 
maintained on a per TPDU or on a per transport connection 
basis, throughput considerations have to be taken into 
account. 

2 For DT TPDUs it is a local choice to retransmit either only 
the* first DT TPDU or all TPDUs waiting for an 
acknowledgment up to the upper window edge. 

3 It is recommended that after N transmissions, the transport 
entity waits T1 + W + Mpn to provide a higher possibility for 
receiving an acknowledgment before entering the release 
phase. For other TPDU types which may be retransmitted, it is 
recommended that after N transmissions th^ transport entity 
waits 7/ + Mri^ to provide an higher possibility of receiving the 
expected reply. 
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4 If use of selective acknowledgdment has been negotiated, a 
selective acknowledgement implicitly identifies DT TPDUs not 
received. Since such a DT TPDU could be a lost OT TPDU, or 
simply a delayed OT TPDU, it is a local matter whether DT 
TPDUs not acknowledged in a selective acknowledgement 
^ould be retransmitted immediately. 

h) concatenation and separation (see 6.4). 

1^.2.2 Procedures for connection establishment 

12.2.2.1 Timers used in connection establishnnent 
There are no timers specific to connection establishment. 



12.2.2.2 

CONS 



General procedures when operating over 



The transport entities shall use the following procedures: 

a) assignment to network connection (see 6,1.1 ); 

When a network connection to which the transport 
connection is assigned is released (NDISind received): 

1 ) if a CC TPDU is awaited the initiator shall perform 
a new assignment according to QOS and the 
retransmission procedure (i.e. not sending the CR 
TPDU for more than /V* 77); 

2) if there is at least one other network connection 
to which the transport connection is assigned both 
initiator and acceptor may either perform a new 
assignment or continue operation using one of the 
remaining network connections; 

3) if the transport connection becomes unassigned 
the acceptor may either perform a new assignment 
or wait (there is no risk of deadlock as either T1 or li_ 
will be running); the initiator shall perform a new 
assignment (except in the closing state); 

b) connection establishment (see 6.5) and if appropriate 
connection refusal (see 6.6) together with the additional 
procedures: 

1) a connection is not considered established until 
the successful completion of a 3-way TPDU 
exchange. The sender of a CR TPDU shall respond 
to the corresponding CC TPDU by immediately 
sending a DT, ED, DR, or AK TPDU; 

2) as a result of duplication or transmission, a CR 
TPDU may be received specifying a source 
reference which is already in use with the sending 
transport entity. If the receiving transport entity is in 
the data transfer phase, having completed the 3-way 
TPDU exchange procedure, or is waiting for the T- 
CONNECT response from the TS-user, the receiving 
transport entity shall discard such a TPDU. 
Otherwise a CC TPDU shall be transmitted. 

3) as a result of duplication or retransmission, a CC 
TPDU may be received specifying a paired reference 
which is already in use. The receiving transport 



entity shall only acknowledge the duplicate CC 
TPDU according to the procedure in 12.2.2.2.b)1); 

4) a CC TPDU may be received specifying a 
reference which is in the frozen state. The response 
to such a TPDU shall be a DR TPDU; 

5) the retransmission procedures (see 12.2.1.2) are 
used for both the CR TPDU and CC TPDU. 

NOTE - After receiving a CR TPDU, it is recommended that the 
transport entity enforce a time limit upon the transport service user 
so that late acceptance of the transport connection will r.ot cause a 
delayed CC TPDU to be sent. 

12.2.2.3 General procedures when operating over CLNS 

The transport entity shall use the procedure of connection 
establishment (see 6.5) and if appropriate connection 
refusal (see 6.6) together with the additional procedures: 

1) a connection is not considered established until the 
successful completion of a three-way TPDU exchange. 
The sender of a CR TPDU shall respond to the 
corresponding CC TPDU by immediately sending a DT, 
ED, DRorAK TPDU; 

2) as a result of duplication or retransmission, a CR 
TPDU may be received specifying a source reference 
which is already in use with the sending transport entity. 
If the receiving transport entity is in the data transfer 
phase, having completed the three-way TPDU 
exchange procedure, or is waiting for the T-CONNECT 
response from the TS-user, the receiving transport entity 
shall discard such a TPDU. Otherwise a CC TPDU 
shall be transmitted; 

3) as a result of duplication or retransmission, a CC 
TPDO may be received specifying a paired reference 
which is already in use. The receiving transport entity 
shall only acknowledge the duplicate CC TPDU 
according to the procedure in 12,2.2.3.1); 

4) a CC TPDU may be received specifying a reference 
which is in the frozen state. The response to such a 
TPDU shall be a DR TPDU; 

5) the retransmission procedures (see 12.2.1.3) are 
used for both the CR TPDU and CC TPDU. 

NOTE - After receiving a CR TPDU, it is recommended that the 
transport entity enforce a time limit upon the transport service user 
so that late acceptance of the transport connection will not cause a 
delayed CC TPDU to be sent. 

12.2.3 Procedures tor data transfer 



12.2.3.1 Timers used in data transfer 

12.2.3.1.1 Timers used in data transfer when operating 
over CONS 

The data transfer procedures use one additional timer: 

a) Window timer ( 1/V) 
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A transport entity maintains a timer interval to ensure 
that there is a bound on the maximum interval between 
window updates. 

NOTE - A suitable upper bound value for W is such that W < 
Ifj-ELfj. It is recommended that the value for W bs 
sufficiently less than (/^ - Elr) such that the inactivity control 
procedure in 12.2.3.3 can be operated having regard to the 
possibility of TPDU loss. 



12.2.3.1.2 

over CLNS 



Timers used in data transfer when operating 



The data transfer procedures use one additional timer: 

a) Window timer (MO 

A transport entity maintains a timer interval to ensure 
that there is a bound on the maximum interval between 
window updates. 

NOTE - A suitable upper band value for Wis such that W < Ipf 
- Eip. It is recommended that the value for W be sufficiently 
less than (Ip^ ~ Efj^ such that the inactivity control procedure in 
12.2.3.3 can be operated having regard to the possibility of 
TPDU loss. 



12.2.3.2 General procedures for data transfer 

The transport entities shall use the following procedures: 

a) inactivity control (see 6.21); 

b) expedited data (see 6.1 1); 

c) Explicit flow control (see 6.1 6). 

The sending transport entity shall use the following 
procedures in the following order: 

1 ) segmenting (see 6.3); 

2) DT TPDU numbering (see 6.10). 

The receiving transport entity shall use the following 
procedures in the following order: 

- DT TPDU numbering (see 6.10); 

- resequencing (see 6.20); 

- reasfsembling (see 6.3). 

12.2.3.3 Inactivity control 

If the interval of the inactivity timer I expires without receipt 
of some TPDU, the transport entity shall initiate the release 
procedures. To prevent expiration of the remote transport 
entity's inactivity timer when no data is being sent, the local 
transport entity must s6nd AK TPDUs at suitable intervals in 
the absence of data, having regard to the probability of 



TPDU loss. The window syncnronization procedures (see 
12.2,3.8) ensure that this requirement is met. 

NOTE - It is likely that the release procedure initiated due to the 
expiration of the inactivity timer will fait, as such expiration indicates 
probable failure of the supporting network connection or of the 
remote transport entity. 



12.2.3.4 Expedited data 

1 2.2.3.4.1 Expedited data when operating over CONS 

The transport entities shall follow the network normal data 
variant of the expedited data transfer procedures (see 
6,11.1), if the use of the transport expedited service option 
has been agreed during connection establishment. 

The ED TPDU shall have a TPDU-NR which is allocated 
from a separate sequence space from that of the DT 
TPDUs. 

A transport entity shall allocate the sequence number zero 
to the ED TPDU-NR of the first ED TPDU which it transmits 
for a transport connection. For subsequent ED TPDUs sent 
on the same transport connection, the transport entity shall 
allocate a sequence number one greater than the previous 
one. 

Modulo 2^ arithmetic shall be used when normal formats 
have been selected and modulo 2^' arithmetic shall be used 
when extended formats have been selected. 

The receiving transport entity shall transmit an EA TPDU 
with the same sequence number in its YR-EDTU-NR field. 
If this number is one greater than in the previously received 
in-sequence ED TPDU, the receiving transport entity shall 
transfer the data in the ED TPDU to the TS-user. 

If a transport entity does not receive an EA TPDU in 
acknowledgement to an ED TPDU it shall follow the 
retransmission procedures (see note and 1 2.2.1 .2). 

The sender of an ED TPDU shall not send any new DT 
TPDU created from a T-DATA request subsequent to the T- 
EXPEDITED DATA request, until it receives the EA TPDU. 

NOTE - This procedure ensures that ED TPDUs are delivered to 
the TS-user in sequence and that the TS-user does not receive 
data corresponding to the same ED TPDU more than once. Also it 
guarantees the arrival of the ED TPDU before any data 
subsequently sent by the TS user. 



12.2.3.4.2 Expedited data when operating ovfer CLNS 

The transport entities shall follow the expedited data 
transfer procedures in 6,11.2, if the use of the transport 
expedited data service option has been agreed during 
connection establishment. 

The ED TPDU shall have a TPDU-NR which is allocated 
from a separate sequence space from that of the DT 
TPDUs. 
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A transport entity shall allocate the sequence number zero 
to the ED TPDU-NR of the first ED TPDU which it 
transmits for a transport connection. For subsequent ED 
TPDUs sent on the same transport connection, the transport 
entity shall allocate a sequence number one greater than 
the previous one. 

Modulo 2^ arithmetic shall be used when normal formats 
have been selected and modulo 2^' arithmetic shall be used 
when extended formats have been selected. 

The receiving transport entity shall transmit an EA TPDU 
with the same sequence number in its YR-EDTU-NR field. 
If this number is one greater than in the previously received 
in-sequence ED TPDU, the receiving transport entity shall 
transfer the data in the ED TPDU to the TS-user. 

If a transport entity does not receive an EA TPDU in 
acknowledgment to an ED TPDU it shall follow the 
retransmission procedures (see note and 12.2.1.3). 

The sender of an ED TPDU shall not send any new DT 
TPDU created from a T-DATA request subsequent to the T- 
EXPEDITED DATA request, until it receives the EA TPDU. 

NOTE - This procedure ensures that ED TPDUs are delivered to 
the TS-user in sequence and that the TS-user does not receive 
data corresponding to the same ED TPDU more than once. Also it 
guarantees the arrival of the ED TPDU before any data 
subsequently sent by ttie TS user. 

12.2.3.5 Resequencing 

The receiving transport entity shall deliver all DT TPDUs to 
the TS-user in the order specified by the sequence number 
field. 

DT TPDUs received out-of-sequence but within the transmit 
window shall not be delivered to the TS-user until all in- 
sequence TPDUs have been received. DT TPDUs received 
out-of-sequence and outside the transmit window shall be 
discarded but may result in transmission of an AK TPDU 
with up-to-date window information (see 12.2.3.8). If the 
selective acknowledgement option has been agreed to at 
connection establishment, DT TPDUs that have been 
selectively acknowledged shall be retained by the receiving 
transport entity until delivered to the TS-user. They shall be 
retained even if the selectively acknowledged DT TPDUs 
later fall outside the transmit window due to a subsequent 
credit reduction. 

NOTE - It is recommended that the transport entity sending the AK 
TPDU maintains a bound on the number of times a DT TPDU is 
selectively acknowledged in order to reduce the processing at the 
transport entity receiving the AK TPDU. 

Duplicate TPDUs can be detected because the sequence 
number matches that of previously received TPDUs. 
Sequence numbers shall not be reused for the period L after 
their previous use. Othenvise, a new, valid TPDU could be 
contused with a duplicated TPDU which had previously 
been received and acknowledged. 



Duplicated DT TPDUs shall be acknowledged, since the 
duplicated TPDU may be the result of a retransmission 
resulting from the loss of an AK TPDU. 

The data contained in a duplicated DT TPDU shall be 
discarded. 



12.2.3.6 



Explicit flow control 



The transport entities shall send an initial credit (which may 
take the value 0) in the CDT field of the CR TPDU or CC 
TPDU. This credit represents the initial value of the upper 
window edge of the peer entity. 

The transport entity which receives the CR TPDU or CC 
TPDU shall consider its lower window edge as zero and its 
upper window edge as the value in the CDT field in the 
received TPDU. 

In order to authorize the transmission of DT TPDUs by its 
peer, a transport entity may transmit an AK TPDU at any 

time. 

The sequence number of an AK TPDU shall not exceed the 
sequence number of the next expected DT TPDU, i.e. it 
shall not be greater than the highest sequence number of a 
received DT TPDU, plus one. 

A transport entity may send a duplicate AK TPDU 
containing the same sequence number, CDT, and 
subsequence number field at any time. 

A transport entity may increase or decrease the upper 
window edge at any time. 

A transport entity which receives an AK TPDU shall 
consider the value of the YR-TU-NR field as its new lower 
window edge if it is greater than any previously received in a 
YR-TU-NR field, and the sum of YR-TU-NR and COT as its 
new upper window edge subject to the procedures for 
sequencing AK TPDUs (see 12.2.3.8). A transport entity 
shall not transmit or retransmit a DT TPDU with a sequence 
number outside the transmit window. 



12.2.3.7 Sequencing of received AK TPDUs 

To allow a receiving transport entity to properly sequence a 
series of AK TPDUs that all contain the same sequence 
number and thereby use the correct CDT value, AK TPDUs 
may contain a subsequence parameter. For the purpose of 
determining the correct sequence of AK TPDUs, the 
absence of the subsequence parameter shall be equivalent 
to the value of the parameter set to zero. 

An AK TPDU is defined to be in sequence if 

a) the sequence number is greater than any previously 
received AK TPDU, or 

b) the sequence number is equal to the highest in any 
previously received AK TPDU, and the subsequence 
parameter is greater than in any previously received AK 
TPDU having the same value for YR-TU-NR field, or 
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c) the sequence number and subsequence parameter 
are both equal to the highest in any previously received 
AK TPDU and the credit field is greater than or equal to 
that in any previously received AK TPDU having the 
same YR-TU-NR field. 

When the receiving transport entity recognizes an out-of- 
sequence AK TPDU it shall discard it. 

12.2.3.8 Procedures for transmission of AK TPDUs 



12.2.3.8.1 



Transmission of AK TPDUs 



An in-sequence DT TPDU shall be acknowledged within 
time Al, by the transmission of an AK TPDU whose YR-TU- 
NR parameter is set to at least the sequence number of the 
received DT TPDU plus one. If the selective 
acknowledgement option has been agreed to at connection 
establishment, out of sequence DT TPDUs may also be 
acknowledged within time Ai^. The YR-TU-NR parameter 
shall be set to one greater than the highest sequence 
number of, an in-sequence DT TPDU and the selective 
acknowledgement parameter will be appropriately set. 

An AK TPDU shall be transmitted containing up-to-date 
window information if 

a) a DT TPDU is received whose sequence number is 
lower than the lower window edge, but greater than or 
equal to the lower window edge minus the maximum 
credit value ever given for this transport connection, or 

b) a DT TPDU is received whose sequence number is 
above the current upper window edge, but following 
credit reduction is within the upper window edge which 
has been granted and then withdrawn. 

NOTES 

1 A simpler implementation may send an AK TPDU upon 
reception of any DT TPDU outside frie transmit window. 

2 The procedure a) is required so that loss of an AK TPDU is 
correctly recovered, i.e. when the sender of the DT TPDU 
retransmits it following non-receipt of an acknowledgement. 

3 The procedure b) is required due to the possibility of loss of the 
AK TPDU indicating the upper window edge reduction, which could 
otherwise cause incorrect termination of the transport connection. 

4 Wherever procedures a) and b) are invoked and selective 
acknowledgement option is being used, the selective 
acknowledgement parameters, if required, of the AK TPDU will be 
appropriately set. 

A transport entity shall not allow an interval W to pass 
without the transmission of an AK TPDU. If the transport 
entity is not using the procedure following setting CDT to 
zero (see 12.2.3.8.3) or reduction of the upper window edge 
(see 12.2.3.8.4), and does not have to acknowledge receipt 
of any DT TPDU, then it shall achieve this by retransmission 
of the most recent AK TPDU, with up-to-date window 
information. 



NOTE - The use of the procedures defined in 12.2.3.8.3 and 
12.2.3.8.4 is optional for any transport entity. The protocol operates 
correctly either with or without these procedures which are defined 
to enhance the efficiency of its operation. 



12.2.3.8.2 

TPDUs 



Sequence control for transmission of AK 



To allow the receiving transport entity to process AK TPDUs 
in the correct sequence, as described in 12.2.3.7, the 
subsequence parameter shall be included following 
reduction of CDT. If the value of the subsequence number 
to be transmitted is zero, then the parameter should be 
omitted. 

The value of the subsequence parameter, if used, shall be 
zero (either explicitly or by absence of the parameter) if the 
sequence number is greater than the parameter in previous 
AK TPDUs, sent by the transport entity. 

If the sequence number is the same as the previous AK 
TPDU sent and the CDT field is equal to or greater than the 
CDT field in the previous AK TPDU sent then the 
subsequence parameter, if used, shall be equal to that in 
the previously sent AK TPDU. 

If the sequence number is the same as the previous AK 
TPDU sent and the CDT field is less than the value of the 
CDT field in the previous AK TPDU sent then the 
subsequence parameter, if used, shall be one greater than 
the value in the previous AK TPDU. 

NOTE - If a transport entity never reduces credit, then it does not 
need to use the subsequence number. 



12.2.3.8.3 

to zero 



Retransmission of AK TPDUs after CDT set 



Due to the possibility of loss of AK TPDUs, the upper 
window edge as perceived by the transport entity 
transmitting an AK TPDU may differ from that perceived by 
the intended recipient. To avoid the possibility of extra 
delay, the retransmission procedure (see 12.2.1.2 and 
12.2.1.3) can be followed for an AK TPDU, if it opens the 
transmit window which has previously been closed by 
sending an AK TPDU with CDT field set to zero. 

The retransmission procedure, if used, terminates and the 
procedure in 12.2.3.8.1 is used when 

a) an AK TPDU is received containing the flow control 
confirmation parameter, whose lower window edge and 
your subsequence fields are equal to the sequence 
number and subsequence number in the retained AK 
TPDU and whose credit field is not zero; 

b) an AK TPDU is transmitted with a sequence number 
higher than that in the retained AK TPDU, due to 
reception of a DT TPDU whose sequence number is 
equal to the lower window edge; 

c) N transmissions of the retained AI^TPDU have taken 
place. In this case the transport entity shall continue to 
transmit the AK TPDU at an interval of W. 
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An AK TPDU which is subject to the retransmission 
procedure shall not contain the flow control confirmation 
parameter. If it is required to transmit this parameter 
concurrently, an additional AK TPDU shall be transmitted 
having the same values in the sequence, subsequence (if 
applicable) and credit fields. 

12.2.3.8.4 Retransmission procedures following 
reduction of the upper window edge 

This sub-clause specifies the procedure for retransmission 
of AK TPDUs after a transport entity has reduced the upper 
window edge (see 12.2.3.6). This procedure is used until 
the lower window edge exceeds the highest value of the 
upper window edge ever transmitted (i.e. the value existing 
at the time of credit reduction, unless a higher value is 
retained from a previous credit reduction). 

The retransmissk)« procedure should be followed for any 
AK TPDU which increases the upper window edge, unless it 
is known that the remote transport entity has an open 
window. This is known if 

- a flow control confirmation (FCC) parameter has 
been received corresponding to an AK TPDU 
transmitted following the most recent credit reduction, 
and: 



The rules for determining whether to apply the retransmission 
procedure to an AK TPDU may be expressed altematively as 
follows. Let 

LWE = lower window edge 

UWE = upper window edge 

KUWE = lower bound on upper window edge held by remote 
transport entity. 

The retransmission procedure is to be applied whenever 

(UWE > LWE) and (KUWE = LWE) 

i.e. when the window Is opened and it is not known definitely that 
the remote transport entity is aware of this. 

KUWE is maintained as fotTows: 

When credit is reduced, KUWE is set to LWE. Subsequently, it is 
increased only upon receipt of a valid flow control confirmation (i.e. 
one which matches the retained lower window edge and 
subsequence). In this case KUWE is set to the implied upper 
window edge of the flow control confirmation, i.e. the sum of its 
lower window edge and your credit fields. By using this method, it 
can be ensured that KUWE is always less than or equal to the 
actual upper window edge used by the transmitter of DT TPDUs. 



- this FCC parameter conveys an upper window edge 
value (i.e. the sum of the lower window edge and credit 
fields) which is greater than the lower window edge of 
the transmitted AK TPDU. 

This retransmission procedure for any particular AK TPDU 
shall termmate when 

a) an AK TPDU is received containing the flow control 
corfimnaticn parameter, whose lower window edge and 
your subaeqyence fields are equal to the lower window 
edge and subsequence number in the retained AK 
TPDU; or 

b) N transmissions of the retained AK TPDU have taken 
place. In this case the transport entity shall continue to 
transmit the AK TPDU at an interval of W. 

An AK TPDU which is subject to the retransmission 
procedure shall not contain ihe flow control confirmation 
parameter. If it is required to transmit this parameter 
concurrently, an additional AK TPDU shall be transmitted 
having the same values in the sequence, subsequence (if 
applicable) and credit fields. 

NOTE - Retransmission of AK TPDUs is normally not necessary, 
except following explicit closing of the window (i.e. transmission of 
an AK TPDU with COT field set to zero). If data are available for 
transmission; the retransmission procedure for DT TPDUs will 
ensure that an AK TPDU is received granting further credit where 
this is available; following credit reduction, this may no longer be 
so, because retransmission may be inhibited by the credit 
reduction. The rules described in this clause avoid extra delay. 



12.2.3.9 Use of flow control confirmation parameter 

An AK TPDU containing a flow control confirmation 
parameter may be transmitted at any time. The lower 
window edge, your subsequence and your credit fields shall 
be set to the same values as the corresponding fields in the 
most recently received in-sequence AK TPDU. 

An AK TPDU containing a flow control confirmation 
parameter should be transmitted whenever 

a) a duplicate AK TPDU is received, with the value of 
YR-TU-NR,. CDT, and subsequence fields equal to the 
most recently received in sequence AK TPDU, but not 
itself containing the flow control confirmation parameter; 

b) an AK TPDU is received which increases the upper 
window edge but not the lower window edge, and the 
upper window edge was formerly equal to the lower 
window edge; or 

c) an AK TPDU is received which increases the upper 
window edge but not the lower window edge, and the 
lower window edge is lower than the highest value of the 
upper window edge received and subsequently reduced 
(i.e. following credit reduction). 

12.2.4 Procedures for release 



12.2.4.1 Timers used for release 
There are no timers used only for release. 
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1 2.2.4.2 General procedures for release 

The transport entity shall use the explicit variant of normal 
release (see 6.7). 



Although the retransmission procedure also apply to the DR 
TPDU in the release phase, the transport entity may 
however consider that the transport connection has been 
released if it would be necessary to open a new network 
connection in order to retransmit the DR TPDU. 
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13 Structure and encoding of TPDUs 

13.1 Validity 

Table 8 specifies those TPDUs which are valid for each class and the code for each TPDU. 

Table 8 - TPDU codes 





Validity within classes 


See sub- 
clause 


Code 





1 


2 


3 


4 


CR: connection request 


X 


X 


X 


X 


X 


13.3 


1110 XXXX 


CO: connection confirm 


X 


X 


X 


X 


X 


13.4 


1101 XXXX 


DR: disconnect request 


X 


X 


X 


X 


X 


13.5 


1000 0000 


DC: disconnect confirm 




X 


■ 

X 


X 


X 


13.6 


1100 0000 


DT: data 


X 


X 


X 


X 


X 


13.7 


1111 OOOy 


ED; expedited data 




X 


NF 


X 


X 


13.8 


0001 0000 


AK; data acknowledgement 




NRC 


NF 


X 


X 


13.9 


0110 zzzz 


EA: expedited data acknowledgement 




X 


NF 


X 


X 


13.10 


0010 0000 


RJ: reject 




X 




X 




13.11 


0101 zzzz 


ER: TPDU error 


X 


X 


X 


X 


X 


13.12 


0111 0000 


Not available (see the note) 












-- 


0000 0000 














0011 0000 














1001 XXXX 












- 


1010 XXXX 





Key: 

XXXX (bits 4 to 1 ): used to signal the CDT (set to 0000 in classes to 1). 

zzzz (bits 4 to 1 ): used to signal CDT in classes 2,3,4 set to 1 1 1 1 in class 1 . 

y (bit 1): used to signal ROA if the request acknowledgement procedure has been agreed at connection establishment (classes 1 , 3, 4 only). 
This bit shall be set to if the request acknowledgement procedure has not been agreed. 

NF: Not available when the non-explicit flow control option is selected. 

NRC: Not available when th© receipt confirmation option is selected. 

NOTE -These codes are already in use in related protocols defined by standards organizations other than CCITTand ISO/IEC. 



13.2 Structure 

Ail the transport protocol data units (TPDUs) shall contain an integral number of octets. The octets in a TPDU are numbered 
starting from 1 and increasing in the order they are put into an NDSU. The bits in an octet are numbered from 1 to 8, where bit 
1 is the lowest order bit. 

When consecutive octets are used to represent a binary number, the lower octet number has the most significant value* 
NOTES 
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1 The numbering of bits within an octet is a convention local to this International Standard. 

2 The use of the terms 'high order" and "low order" is common to this International Standard and to adjacent layer standards. 

3 The use of the above conventions does not affect the order of bit transmission on a serial communications link. 

4 As described in 6.2.3, both transport entities respect these bit and octet ordering conventions, thus allowing communication to take place. 

5 In this clause the encoding of TPDUs is represented in the following form: 

a) octets are shown with the lowest numbered octet to the left; higher numbered octets being further to the right; 

b) within an octet, bits are shown with bit 8 to the left and bit 1 to the right. 
TPDUs shall contain, in the following order: 

a) the header, comprising 

1 ) the length indicator (LI) field; 

2) the fixed part; 

3) the variable part, if present; 

b) the data field, if present. 
The structure is illustrated below: 



Octets 

1 


2 3 4 ... n 


n+1 ... p 


p+1 


end 


Lt 


Fixed part 


Variable part 


Data Field 


■^ 


— — — — - header - 


______ ^-^ 







13.2.1 Length indicator field 

The field is contained in the first octet of the TPDUs. The length is indicated by a binary number, with a maximum value of 254 
(1111 1110). The length indicated shall be the header length in octets including parameters, but excluding the length indicator 
field and user data, if any. The value 255 (1111 1 1 1 1 ) is reserved for possible extensions. 

If the length indicated exceeds or is equal to the size of the NS-user data which is present, this is a protocol error. 

13.2.2 Fixed part 

13.2.2.1 General 

The fixed part contains frequently occurring parameters including the code of the TPDU. The length and the structure of the 
fixed part a'e defined by the TPDU code and in certain cases by the protocol class and the formats in use (normal or extended). 
If any of the parameters of the fixed part have an invalid value, or if the fixed part cannot be contained within the header (as 
defined by LI), this is a protocol error. 

NOTE - In general, the TPDU code defines the fixed part unambiguously. However, different variants may exist for the same TPDU code (see 
normal and extended formats). 

13.2.2.2 TPDU code 

This field contains the TPDU code and is contained in octet 2 of the header. It is used to define the structure of the remaining 
header. This field is a full octet except in the following cases: 



1110 xxxx 
1101 xxxx 



Connection request 
Connection confirm 
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1111 OOOy Data 

0101 xxxx Reject 

0110 xxxx Data acknowledgement 

where 

xxxx (bits 4 to 1 ) is used to signal the CDT. 

y (bit 1) is used to signal ROA if the request acknowledgement has been agreed at connection establishment (class 1 , 3, 4 
only). 

Only those codes defined in 13,1 are valid. 
13.2.3 Variable part 

The variable part is used to define less frequently used parameters. If the variable part is present, it shall contain one or more 
parameters. 

NOTE - The number of parameters that may be contained in the variable part is indicated by the length of the variable part which is LI minus 
the length of the fixed part. 

Each parameter contained within the variable part is structured as follows: 

Octets Bits 8 7 6 5 4 3 2 1 



n + 1 

n + 2 

n + 3 

n + 2 + m 



Parameter code 



Parameter length indication (for example m) 



Parameter value 



The parameter code field is coded in binary. 

NOTE - Without extensions, it provides a maximum number of 255 different parameters. However, as noted below, bits 8 and 7 cannot take 
every possible value, so the practical maximum number of different parameters is less. Parameter code 1111 1111 is resen/ed for possible 
extensions of the parameter code. 

The parameter length indication indicates the length, in octets, of the parameter value field. 

NOTE - The length is indicated by a binary number, m, with a theoretical maximum value of 255, The practical maximum value of m is lower. 
For example, in the case of a single parameter contained within the variable part, two octets are required for the parameter code and the 
parameter length indication itself. Thus, the value of m is limited to 248. For larger fixed parts of the header and for each succeeding 
parameter, the maximum value of m decreases. 

The parameter value field contains the value of the parameter identified in the parameter code field. 

No parameter code uses bits 8 and 7 with the value 00. 

The parameters defined in the variable part may be in any order. If any parameter is duplicated then the last value shall be 
used. A parameter not defined in this International Standard shall be treated as a protocol error in any received TPDU except a 
CR TPDU; in a CR TPDU it shall be ignored. A called TSAP-ID parameter in a CC TPDU with a length indicator set to zero 
shall be treated as having the "nil selector value" (see ISO/IEC 7498-3, 9.5.2). If the responding transport entity selects a class 
for which a parameter of the CR TPDU is not defined, it may ignore this parameter, except if it is the class and option 
parameter, or the alternative protocol class parameter which shall always be interpreted. A parameter defined in this 
International Standard but having an invalid value shall be treated as a protocol error in any received TPDU except a CR TPDU. 
In a CR TPDU it shall be treated as a protocol error if it is either the class and option parameter or the alternative class 
parameter; bits 8 to 7, and bits 6 to 1, if not meaningful for the class proposed, of the additional options parameter shall be 
ignored; otherwise it shall be either ignored or treated as a protocol error. 
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13.2.3.1 Checksum parameter {class 4 only) 

All TPDU types may contain a 16-bit checksum parameter in their variable part. This parameter shall be present in a CR TPDU 
and shall be present in al! other TPDUs except when the non-use of checksum option is selected. 

Parameter code: 1 1 00 001 1 

Parameter length: 2 

Parameter value: Result of checksum algorithm; this algorithm is specified in 6.1 7. 

13.2.4 Data field 

This field contains transparent user data. Restrictions on its size are noted for each TPDU. 

1 3.3 Connection request (CR) TPDU 

The length of the CR TPDU shall not exceed 128 octets. 

13.3.1 structure 

The structure of the CR TPDU shall be as follows: 

1 2 3 4 56 7 8pp+1 end 



1^1 CR CDT 
1 1 1 xxxx 


1 

DST-REF 

0000 0000 0000 0000 

1 


1 

SRC-REF 

1 


CLASS 
OPTION 


Variable 
part 


User 
Data 



13.3.2 LI 

See 13.2.1. 

13.3.3 Fixed part {octets 2 to 7) 

The structure of this part shall contain: 

a) CR: Connection request code: 1110. Bits 8 to 5 of octet 2; 

b) COT- iniiial credit allocation (set to 0000 in classes and 1 when specified as preferred class). Bits 4 to 1 of octet 2; 

c) DST-REF: Set to zero; 

d) SRC-REF: Reference selected by the transport entity initiating the CR TPDU to identify the requested transport 
connection; 

e) CLASS and OPTION: Bits 8 to 5 of octet 7 define the preferred transport protocol class to be operated over the 
requested transport connection. When operating over CONS, this field shall take one of the following values: 

GOOD Class 

0001 Class 1 

0010 Class 2 

0011 Class 3 
0100 Class 4 

When operating over CLNS, this field shall take the value 0100 to indicate class 4. ' 
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The CR TPDU contains the first choice of class in the fixed part. Second and subsequent choices are listed in the variable part 
if required. 

Bits 4 to 1 of octet 7 define options to be used on the requested transport connection as follows: 



BIT 


OPTION 


4 


= Always 




3 


= Always 




2 


= Use of nornnal formats in all classes 






= 1 Use of extended formats in classes 2, 3, 


and 4 


1 


= Use of explicit flow control in class 2 
= 1 No use of explicit flow control in class 2 





Bits related to options particular to a class are not meaningful if that class is not proposed and may therefore take any value. 
NOTES 

1 The connection establishment procedure (see 6.5) does not permit a given CR TPDU to request use of transport expedited data transfer 
sen/ice (additional pption parameter) and not use of explicit flow control in class 2 (bit 1 = 1). 

2 Bits 4 to 1 are always zero in class and have no meaning. 

13.3.4 Variable part (octets 8 to p) 

The following parameters are permitted in the variable part: 

a) Transport Service Access Point Identifier (TSAP-ID) 
Parameter code: 1 1 00 0001 for the identifier of the calling TSAP 

1 1 00 00 1 for the identifier of the called TSAP 
Parameter length: not defined in this International Standard 
Parameter value: identifier of the calling or called TSAP respectively. 

If a TSAP-ID is given in the request it may be returned in the confirmation. • 

b) TPDU size 

This parameter defines the proposed maximum TPDU size (in octets including the header) 1o be used over the requested 
transport connection. The coding of this parameter is 

Parameter code: 1 1 00 0000 

Parameter length: 1 octet 

Parameter value: 

0000 1101 8 192 octets (not allowed in class 0) 

0000 1 1 00 4 096 octets (not allowed in class 0) 

0000 1011 2 048 octets 

0000 1010 1 024 octets 

0000 1001 512 octets 

0000 1000 256 octets 

0000 0111 128 octets 

Default value: 0000 01 1 1 (128 octets). 
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c) Preferred maximum TPDU size 

This parameter defines \he proposed maximum TPDU size (in octets including ttie Header) to be used over the requested 
transport connection. 

The coding of this parameter is: 

Parameter Code: 1111 0000 

Parameter length: up to 4 

Parameter value: a binary value. The binary value indicates the maximum TPDU size, expressed as a multiple of 1 28 
octets [see 6.5.4 m) and 6.5.5 m)]. This binary value shall be greater than or equal to 1 . 

d) Version number (not used if class is the preferred class) 
Parameter code: 1 1 00 01 00 

Parameter length: 1 octet 

Parameter value field: 0000 0001 

Default value: 0000 0001 (not used in class 0). 

e) Protection parameters (net ur.ed is class is the preferred class) 
This parameter is user defined. 

Param.ster code: 1100 0101 

Parameter length: user defined 

Parameter vaiuo: user defined. 

t) Checi^sum (used only if ciass 4 is the preferred class ) (see 13.2.3.1) 

This parameter shall always be present in a CR TPDU requesting class 4, even if the checksum selection parameter is used 
to request non-use of the checksum facility. 

g) Additional option selection (not used if class is the preferred class) 

Tiiis parameter defines the selection to be made as to whether or not additional options are to be used. 

Parameter code: 1100 0110 

Parameter length: 1 

Parameter value: 



BIT 


OPTION 


6 


= 1 Use of request acknowledgement in class 1,3,4 




= Non-use of request acknowledgement in classes 1 , 3, 4 


5 


= 1 Use of selective acknowledgement in class 4 




= Non-use of selective acknowledgement in class 4 


4 


= 1 Use of network expedited in class 1 




- Non-use of network expedited in class 1 
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= 1 Use of receipt confirmation in class 1 

= Use of explicit AK variant in class 1 

= 16-bit checksum defined in 6.17 shall be used in class 4 

= 1 16-bit checksum defined in 6.17 shall not be used in class 4 

= 1 Use of transport expedited data transfer service 

= Non-use of transport expedited data transfer service 



Default value: 0000 0001 . 

Bits 8 and 7 shall be set to zero when sending the TPDU and ignored upon receipt. 



>+ r^rr\r\f\caA ^nrl ma\/ thkorafr^ra taL'a art\/ 



value. 



h) Alternative protocol class{es) (not used if class is the preferred class or when operating over CLNS) 

Parameter code: 11000111 

Parameter length: n 

Parameter value: Encoded as a sequence of single octets; each encoded as for octet 7 but with bits 4 to 1 set to zero 
(i.e. no alternative option selections permitted). 



This parameter conveys the maximum acknowledgement time A^ to the remote transport entity. It is an indication only, and 
is not subject to negotiation (see 12.2.1.1.3). 

Parameter code: 1 000 0101 

Parameter length: 2 

Parameter value: n, a binary number where n is the maximom acknowledgement time, expressed in milliseconds. 

k) Throughput (not used if class is the preferred class) 

Parameter code: 1000 1001 

Parameter length: 1 2 or 24 

Parameter value: 

1st 12 octets: maximum throughput, as follows: 

First 3 octets: target value, calling-called user direction 

Second 3 octets: minimum acceptable, calling-called user direction 

Third 3 octets: target value, called-calling user direction 

Fourth 3 octets: minimum acceptable, called-calling user direction 

2nd 12 octets (optional): average throughput, as follows: 
Fifth 3 octets: target value, calling-called user direction 
Sixth 3 octets: minimum acceptable, calling-called user direction 
Seventh 3 octets: target value, called-cailing user direction 
Eighth 3 octets: minimum acceptable, called-calling user direction 

Where average throughput is omitted, it is considered to have the same value as the maximum throughput. Values are 
expressed in octets per second. 

m) Residual error rate (not used if class is the preferred class) * 
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Parameter code: 1000 0110 
Parameter length:. 3 
Parameter value: 

1st octet: target value, power of 10 

5nd octet: minimum acceptable, power of 10 

3rd octet: TSDU size of interest, expressed as a power of 2 

n) Priority (not used if class is the preferred class) 

Parameter code: 1000 0111 

Parameter length: 2 

Parameter value: integer (0 is the highest priority) 
p) Transit delay (not used if class is the preferred class) 

Parameter code: 1000 1000 

Parameter length: 8 

Parameter value: 

First 2 octets: target value, calling-called user direction 

Second 2 octets: maximum acceptable, calling-called user direction 

Third 2 octets: target value, called-calling user direction 

Fourth 2 octets; maximum acceptable, called-calling user direction 

Values are expressed in milliseconds, and are based upon a TSDU size of 128 octets. 

q) Reassignment time (not used if class or 2 is the preferred class; if class 4 is preferred and class 3 is an alternate, it 
may be used) 

This parameter conveys the Time to Try Reassignment (TTR) which shall be used when following the procedure for 
reassignment after failure (see 6.12). 

Parameter code: 1000 1011 

Parameter length: 2 

Parameter value: n, a binary number where n is the TTR value expressed in seconds. 

r) Inactivity timer (used only if class 4 is the preferred or selected class) 

This parameter conveys the inactivity timer /^ to the remote transport entity. It is an indication only, and is not subject to 
negotiation (see 12.2.1.1.7). 

Parameter code: 1 1 1 1 001 

Parameter length; 4 

Parameter value: a binary value. This binary value indicates the inactivity time expressed in milliseconds. 

13.3.5 User data (octets p + 1 to the end) 

No user data are permitted in class 0, and are optional in other classes. Where permitted, they shall not exceed 32 octets. 
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13.4 Connection Confirm (CC) TPDU 
13.4.1 Structure 

The structure of the CC TPDU shall be as follows: 
12 3 4 



8 p p + 1 end 



LI 


CC CDT 
1101 xxxx 


DST-REF 
1 


1 

SRC-REF 

1 


CLASS 
OPTION 


Variable 

part 


User 
Data 



13.4.2 LI 

See 13,2.1. 

13.4.3 Fixed part (octets 2 to 7) 

The fixed part shall contain 

a) CC: Connection confirm code: 1 101. Bits 8 to 5 of octet 2; 

b) CDT: Initial credit allocation (set to 0000 in classes and 1 ). Bits 4 to 1 of octet 2; 

c) DST-REF: Reference identifying the requested transport connection at the rennote transport entity; 

d) SRC-REF: Reference selected by the transport entity initiating the CC TPDU to identify the confirmed transport 
connection; 

e) CLASS OPTION: Defines the selected transport protocol class and option to be operated over the accepted transport 
connection according to the negotiation rules specified in 6.5. 

13.4.4 Variable part (octets 8 to p) 

The parameters are defined in 13.3.4 and are subject to the constraints stated in 6.5 (connection establishment). Parameters 
ruled out by selection of an alternative class and option shall not be present. 

13.4.5 User data (octets p -t- 1 to the end) 

No user data are permitted in class 0, and are optional in the other classes. Where permitted, they shall not exceed 32 octets. 
The user data are subject to the constraints of the negotiation rules (see 6.5). 

13.5 Disconnect Request (DR) TPDU 

13.5.1 Structure 

The structure of the DR TPDU shall be as follows: 

12 3 4 5 6 7 8 p p + 1 end 



LI 


DR 

1000 0000 


1 

DST-REF 


1 

SRC-REF 

1 


REASON 


Variable 
part 


User 
Data 



13.5.2 LI 

See 13,2.1. 
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1 3.5.3 Fixed part (octets 2 to 7) 

The fixed part shall contain 

a) DR: Disconnect request code: 1000 0000; 

b) DST-REF: Reference identifying the transport connection at the remote transport entity; 

c) SRC-REF: Reference identifying the transport connection at the transport entity initiating the TPDU. Value zero when 
reference is unassigned; 

d) REASON: Defines the reason for disconnecting the transport connection. This field shai! take one of the following 
values: 

The following values may be used for classes 1 to 4: 

1 ) 1 28 + 0: Normal disconnect initiated by session entity 

2) 128 + 1; Remote transport entity congestion at connect request time 

3) *1 28 + 2: Connection negotiation failed [i.e. proposed class{es) not supported] 

4) 128 + 3: Duplicate source reference detected for the same pair of NSAPs. 

5) 1 28 + 4: Mismatched references 

6) 1 28 + 5: Protocol error 

7) 128 + 6: Not used 

8) 1 28 + 7: Reference overflow 

9) 128 + 8: Connection request refused on this network connection 

10) 128 + 9: Not used 

11) 1 28 + 1 0: Header or parameter length invalid. 

The following values can be used for all classes: 

12) 0: Reason not specified 

13) 1: Congestion at TSAR 

1 4) *2: Session entity not attached to TSAP 

15) *3: Address unknown. 

NOTE - Reasons marked with an asterisk (*) may be reported to the TS-user as persistent, other reasons as transient. 

1 3.5.4 Variable part (octets 8 to p) 

The variable may contain 

a) a parameter allowing additional information related to the clearing of the connection; 

Parameter code: 1110 0000 

Parameter length: any value provided that the length of the DR TPDU does not exceed the maximum agreed TPDU size 
or 128 when the DR TPDU is used during the connection refusal procedure. 

Parameter value: additional information;' the content of this field is user defined. 

b) checksum (see 13.2.3.1). 

13.5.5 User data (octets p + 1 to the end) 

This field shall not exceed 64 octets and is used to carry TS-user data. The successful transfer of this data is not guaranteed 
by the transport protocol. When a DR TPDU is used in class it shall not contain this field. 
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13.6 Disconnect Confirm (DC) TPDU 

This TPDU shall not be used in class 0. 

13.6.1 Structure 

The structure of the DC TPDU shall be as follows: 
12 3 4 



LI 


1 

DC 

1100 0000 

1 


1 

DST-REF 
1 


1 
SRC-REF 

1 


1 

Variable part 

1 



13.6.2 LI 

See 13.2.1. 

13.6.3 Fixed part (octets 2 to 6) 

The fixed part shall contain 

a) DC: Disconnect confirm code: 1100 0000; 

b) DST-REF: see 13.4.3; 

c) SRC-REF: see 13.4.3. 

13.6.4 Variable part 

The variable part shall contain the checksum parameter if the condition defined in 13.2.3.1 applies. 

13.7 Data (DT) TPDU 

13.7.1 Structure 

Depending on the class and the option the DT TPDU shall have one of the following structures: 
a) Normal format for classes and 1 

12 3 4 5 ... end 



LI 


1 
DT ROA 

1111 OOOy 


TPDU-NR 
and EOT 


User data 



b) Normal formal for classes 2, 3 and 4 
1 2 3 



P+1 



end 



LI 


1 

DT ROA 

1111 OOOy 
1 


1 

DST-REF 
1 


TPDU-NR 
and EOT 


Variable 
part 


User data 
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c) Extended lormat for use in classes 2, 3 and 4 when selected during connection establishment 

1 2 3 4 5, 6, 7, 8 9 p p + 1 end 



LI 


1 

DT ROA 

1111 OOOy 

1 


DST-REF 

1 


TPDU-NR 
and EOT 


Variable 
part 


User data 



13.7.2 U 

See 13.2.1. 

13.7.3 Fixed part 

The fixed part shall contain 

a) DT: Data transfer code: bits 8 to 5 shall be set to 1 1 1 1 . Bits 4 to 2 shall be set to zero. 

b) ROA: Request of acknowledgement mark: If the request acknowledgement procedures has not been agreed during 
connection establishment, bit 1 shall be set to in all DT TPDUs. 

When the request acknowledgement procedure has been agreed during connection establishment, bit 1 (ROA) is used to 
request acknowledgement in classes 1,3, and 4. When set to one, ROA indicates that the sending transport entity requests 
an acknowledgement from the receiving transport entity. Othenwise ROA is set to zero. 

c) DST-REF: See 13.4.3; 

d) EOT: When set to ONE, it indicates that the current DT TPDU is the last data unit of a complete DT TPDU sequence 
(end of TSDU). EOT is bit 8 of octet 3 in class and 1 and bit 8 of octet 5 for classes 2, 3 and 4; 

e) TPDU-NR: TPDU send sequence number (zero in class 0). May take any value in class 2 without explicit flow control. 
TPDU-NR is bits 7 to 1 of octet 3 for classes and 1 , bits 7 to 1 of octet 5 for normal formats in classes 2 3, and 4 and bits 7 
to 1 of octet 5 together with octets 6, 7 and 8 for extended format. 

NOTE - Depending on the class, the fixed part of the DT TPDU uses the following octets: 

classes and 1 : octets 2 to 3; 

classes 2, 3, 4 (nomnal format): octets 2 to 5; 

classes 2, 3, 4 (extended format): octets 2 to 8. 

13.7.4 Variable part 

The variable part shall contain the checksum parameter if the condition defined in 13.2.3.1 applies. 

13.7.5 User data field 

This field contains data of the TSDU being transmitted. 

NOTE - The length of this field is limited to the negotiated TPDU size for this transport connection minus 3 octets in classes and 1, and minus 
5 octets (normal header format) or 8 octets (extended header format) in th« other classes. The variable part, if present, may further reduce the 
size of the user data field. 

1 3.8 Expedited data (ED) TPDU 

This ED TPDU shall not be used in class or in class 2 when the no explicit flow control option is selected or when the 
expedited data transfer service has not been selected for the connection. 

13.8.1 Structure 

Depending on the format negotiated at connection establishment the ED TPDU shall have one of the following structures: 
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a) Normal format (classes 1, 2, 3, 4) 
1 2 3 



p+1 



end 



LI 


1 

ED 

0001 0000 

1 


1 

DST-REF 

1 


EDTPDU-NR 
and EOT 


Variable 
part 


User data 



b) Extended format (for use in classes 2, 3 and 4 when selected during connection establishment) 

1 2 3 4 5, 6, 7, 8 9 p p+1 end 





LI 


1 
ED 

0001 0000 

1 


1 

DST-REF 
1 


ED TPDU-NR 
and EOT 


Variable 
part 


User data 


13.8 

See 


.2 U 

13.2.1. 













13.8.3 Fixed part 

The fixed part shall contain 

a) ED: Expedited data code: 0001 0000; 

b) DST-REF: see 13.4.3; 

c) ED TPDU-NR: Expedited TPDU identification number. ED TPDU-NR is used in classes 1 , 3 and 4 and may talte any 
value in class 2, For norma! formats bits 7 to 1 of octet 5 and for extended formats bits 7 to 1 of octet 5 together with octets 
6, 7 and 8; 

d) EOT: End of TSDU always set to 1 (bit 8 of octet 5). 

NOTE - Depending on the format the fixed part shall be either octets 2 to 5 or 2 to 8. 

13.8.4 Variable part 

The variable part shall contain the checksum parameter if the condition defined in 13.2.3.1 applies. 

13.8.5 User data field 

This field contains an expedited TSDU (1 to 1 6 octets). 

13.9 Data acknowledgement (AK) TPDU 

This TPDU shall not be used in class or in class 2 when the no explicit flow control option is selected, nor for class 1 when the 
network receipt confirmation option is selected. 

13.9.1 Structure 

Depending on the class and option agreed the AK TPDU shall have one of the following structures: 
a) Normal format (classes 1 , 2, 3, 4) 

12 3 4 5 6 n 



LI 


1 

AK CDT 

OIIOzzzz 

-I ... 


1 

DST-REF 
1 


YR-TU-NR 


Variable part 
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b) Extended format {for use in classes 2, 3 and 4 when selected during connection establishment) 

1 2 3 4 5, 6, 7, 8 9 10 11 ... p 



LI 


1 
AK 

0110 0000 

1 


1 

DST-REF 

1 


YR-TU-NR 


CDT 


Variable part 



13.9.2 LI 

See 13.2.1. 

13.9.3 Fixed part 

The fixed part shall contain {in octets 2 to 5 when normal format is used or in octets 2 to 1 0) the following parameters: 

a) AK: Acknowledgement code: 0110; 

b) CDT: Credit value (set to 1111 in class 1). CDT is bits 4 to 1 of octet 2 for normal formats and octets 9 and 10 for 
extended formats; 

c) DST-REF: See 13.4.3; 

d) YR-TU-NR: Sequence number indicating the next expected DT TPDU number. For normal formats, bits 7 to 1 of octet 
5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of octet 5 together with 
octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall take the value 0. 

13.9.4 Variable part 

The variable part contains the following parameters: 

a) Checksum if the condition in 13.2.3.1 applies; 

b) Subsequence number when optionally used under the conditions defined in class 4. This parameter is used to ensure 
that AK TPDUs are processed in the correct sequence. If it is absent, this is equivalent to transmitting the parameter with a 
value of zero. 

Parameter code: 1000 1010 

Parameter length: 2 

Parameter value: 1 6-btt subsequence number; 

c) Flow control confirmation when optionally used under the conditions defined in class 4. This parameter contains a copy 
of the information received in an AK TPDU, to allow the transmitter of the AK TPDU to be certain of the state of the receiving 
transport entity {see 12.2.3.9). 

Parameter code: 1 000 1 1 00 

Parameter length: 8 

Parameter value: defined as follows: 

1 ) Lower window edge (32 bits). Bit 8 of octet 1 of the parameter value field is set to zero, the remainder contains the 
YR-TU-NR value of the received AK TPDU. When normal format has been selected, only the least significant seven bits 
(bits 1 to 7 of octet 4 of the parameter value field) of this field are significant. 

2) Your subsequence (16 bits). Contains the value of the subsequence parameter of the received AK TPDU, or zero if 
this parameter was not present. 
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3} Your credit (16 bits). Contains the value of the CDT field of the received AK TPDU. When normal format has been 
selected, only the least significant four bits (bits 1 to 4 of octet 2 of the Your Credit field) of this field are significant. 

d) Selective acknowledgement parameters when optionally used, under conditions defined in class 4, to acknowledge out 
of sequence DT TPDUs received by the entity transmitting the AK TPDU. All consecutive DT TPDUs received shall be 
acknowledged by a single block. Different groups of DT TPDUs that are consecutive within group but not across groups 
shall be acknowledged using separate blocks (e.g., if DT TPDU numbers 3, 4, 5, 7, 8, 12, 13, 14, 15 and 17 are received 
with 3 the first out-of-sequence DT TPDU, then 3, 4, 5 form one group, 7, 8 another and 12, 13, 14, 15 a third, and 1 7 a 
fourth. The corresponding blocks would be (3, 5), (7, 8), (12, 15) and (17, 17)). 

Parameter code: 1 000 1111 

Parameter length: 2n (normal format) or 8n (extended format) octets where n is the number if distinct blocks being 
selectively acknowledged. This length is constrained by the maximum header size of 254 octets. 

Parameter value: In the normal format, the first octet of a pair of two octets shall represent the lower edge and the 
second octet the upper edge of each block. Bit 8 of each octet is set to zero, the remainder 
represents the sequence number of the edge. 

In the extended format, the first four octets of a set of eight octets represent the lower edge and the 
subsequent four octets represent the upper edge. For each edge of four octets, Bit 8 of the first 
octet is not significant and is set to 0; bits 7 to 1 of the first octet together with the second, third and 
fourth octets represent the sequence number. 

Whether normal or extended formats are used, each set of two or eight octets may be repeated as 
many times as there are blocks to be acknowledged. 

13.10 Expedited data acknowledgement (EA) TPDU 

The EA TPDU shall not be used for class 0, or for class 2 when the "no explicit flow control" option is selected, or when the 
expedited data transfer service has not been selected for the connection. 

13.10.1 Structure 

Depending on the option (normal or extended format) the TPDU structure shall be: 
a) Normal format (classes 1 , 2, 3, 4) 

12 3 4 5 6 D 



LI 


1 

EA 

0010 0000 

1 


1 

DST-REF 
1 


YR-EDTU-NR 


Variable part 



b) Extended format (for use in classes 2, 3 and 4 if selected during connection establishment) 
1 2 3 4 5, 6, 7, 8 9 



LI 


1 
EA 

0010 0000 

1 


1 

DST-REF 

1 


YR-EDTU-NR 


Variable part 



13.10.2 LI 

See 13.2.1. 

13.10.3 Fixed part 

The fixed part shall contain (in octets 2 to 5 when normal format is used or in octets 2 to 8) the following parameters: 
a) EA: Expedited acknowledgement code: 0010 0000; 
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b) DST-REF: See 13.4.3; 

c) YR-EDTU-NR: Identification of the ED TPDU being acknowledged. May take any value in class 2. For normal formats 
bits 7 to 1 of octet 5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of octet 5 
together with octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall take the value 0. 

13.10.4 Variable part 

The variable part may contain the checksum parameter (see 13.2.3.1). 

13.11 Reject (R J) TPDU 

The RJ TPDU shall not be used in classes 0, 2. and 4. 

13.11.1 Structure 

The RJ TPDU shall have one of the following formats: 
a) Normal format (classes 1 and 3) 

12 3 4 5 



LI 


1 

RJ COT 

0101 22ZZ 

• 


1 

DST-REF 

1 


YR-TU-NR 



b) Extended format (for use in class 3 if selected during connection establishment) 
1 2 3 4 5, 6. 7, 8 9 10 



LI 


1 

RJ 
0101 0000 

I 


1 

DST-REF 

1 


YR-TU-NR 


COT 



13.11.2 LI 

See 13.2.1. 

13.11.3 Fixed part 

The fixed part shall contain (in octets 2 to 5 when normal format Is used or in octets 2 to 10) the following parameters: 

a) RJ: Reject code: 0101 . Bits 8 to 5 of octet 2; 

b) CDT: Credit value (set to 1 1 1 1 in class 1). For normal formats bits 4 to 1 of octet 2 and for extended formats octets 9 
and 10; 

c) DST-REF: See 13.4.3; 

d) YR-TU-NR: Sequence number indicating the next expected TPDU from which retransmission should occur. For normal 
formats, bits 7 to 1 of octet 5, bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, bits 7 to 1 of 
octet 5 together with octets 6, 7 and 8; bit 8 of octet 5 is not significant and shall take the value 0. 

13.11.4 Variable part 

There is no variable part for this TPDU type. 
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13.12 TPDU error (ER) TPDU 
13.12.1 Structure 

1 2 3 



LI 


1 

ER 

0111 0000 
1 


1 

DST-REF 

1 


REJECT 
CAUSE 


Variable part 



13.12.2 LI 

See 13.2.1. 

13.12.3 Fixed part 

The fixed part stiait contain the following parameters: 

a) ER: TPDU Error code: 0111 0000; 

b) DST-REF: See 13.4.3; 

c) REJECT CAUSE: 

0000 0000 Reason not specified 

0000 0001 Invalid parameter code 

0000 0010 Invalid TPDU type 

0000 0011 Invalid parameter value. 

13.12.4 Variable part 

The variable part may contain the following parameters: 

a) Invalid TPDU 
Parameter code; 1100 0001 

Parameter length: number of octets of the value field 

Parameter value: contains the bit pattern of the rejected TPDU header up to and including the octet which caused the 
rejection. This parameter is mandatory in class 0. 

b) Checksum 

This parameter shall be present if the condition in 13.2.3.1 applies. 
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Section Three: Conformance 



14 Conformance 

14.1 A system claiming to implement the procedures 
specified in this International Standard shall comply with the 
requirements in 14.2 to 14.5. 

14.2 The system shall implement class or class 2 or 
both. This implies operation over CONS. 

14.3 If the system implements class 3 or class 4, it shall 
also implement class 2. 

14.4 If the system implements class 1, it shall also 
implement class 0. 

14.5 For each class which the system claims to 
implement, the system shall be capable of 

a) initiating CR TPDUs or responding to CR TPDUs 
with CC TPDUs or both; 

b) responding to any other TPDU and operating 
network service in accordance with the procedures for 
the class; 

c) operating all the procedures for the class listed as 
mandatory in table 9; 

d) operating those procedures for the class listed as 
optional in table 9 for which conformance is claimed; 

e) handling all TPDUs of lengths up to the lesser value 
of 

1) the maximum length for the class if the preferred 
maximum TPDU size parameter is not implemented 
[see 13.3.4b)]; 

2) the maximum for which conformance is claimed 
(see note 2); 



NOTES 

1 The procedures for classes to 4 are specified in 
clauses 8 to 12 respectively. The procedures refer to the 
elements of procedures specified in clause 6. 

2 The requirement in 14.5 e) indicates that TPDU size of 
128 octets is always implemented. 

14.6 Claims of conformance shall state 

a) which class or classes of protocol are implemented; 

b) whether class 4 can be operated over the 
connectionless-mode network service; 

c) whether the system is capable of initiating or 
responding to CR TPDUs or both; 

d) which of the procedures listed as optional in table 9 
are implemented; 

e) for each class, the maximum size of TPDU 
implemented [see 13.3.4 b) and 13.3.4 c)]. If the 
preferred maximum TPDU size parameter is not 
implemented the value shall be chosen from the 
following list and all values in the list which are less than 
this maximum shall be implemented: 

128, 256, 512, 1 024. 2 048, 4 096 or 8 192 octets. 

If the preferred maximum TPDU size parameter is 
implemented, any maximum size of TPDU that is a 
multiple of 128 octets is allowed. All values, except 0, 
that are a multiple of 128 octets, less than the maximum 
claimed shall be implemented. 

14.7 The supplier of a protocol implementation which is 
claimed to conform to this International Standard shall 
complete a copy of the PICS proforma provided in Annex D 
and shall provide the information necessary to identify both 
the supplier and the implementation. 
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Table 9 - Provision of options 



Procedure 


class 


class 1 


class 2 


class 3 


class 4 


TPDU with checksum 
TPDU without checksum 


not applicable 
mandatory 


not applicable 
mandatory 


not applicable 
mandatory 


not applicable 
mandatory 


mandatory 
optional 


Expedited data transfer 
No expedited data transfer 


not applicable 
mandatory 


mandatory 
mandatory 


mandatory 
mandatory 


mandatory 
mandatory 


mandatory 
mandatory 


Flowcontro! in class 2 
No flow control in class 2 


not applicable 
not applicable 


not applicable 
not applicable 


mandatory 
optional 


not applicable 
not applicable 


not applicable 
not applicable 


Normal formats 
Extended formats 


mandatory 
not applicable 


mandatory 
not applicable 


mandatory 
optional 


mandatory 
optional 


mandatory 
optional 


Use of receipt confirmation in class 1 
No use of receipt confirmation in 
class 1 


not applicable 
not applicable 


optional 
mandatory 


not applicable 
not applicable 


not applicable 
not applicable 


not applicable 
not applicable 


Use of network expedited in class 1 
No use of network expedited in class 

1 


not applicable 
not applicable 


optional 
mandatory 


not applicable 
not applicable 


not applicable 
not applicable 


not applicable 
not applicable 


Use of selective acknowledgement in 
class 4 


not applicable 


not applicable 


not applicable 


not applicable 


optional 


Use of request of acknowledgement 
in classes 1, 3, 4 


not applicable 


optional 


not applicable 


optional 


optional 
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Annex A 

(normative) 
State tables 



A.1 General 

This annex provides a more precise description of the 
protocol. In the event of a discrepancy between the 
description in these tables and that contained in the text, the 
text lakes precedence. 

The state tables also define the mapping between service 
and protocol events that TS-users can expect. 

This annex describes the transport protocol in terms of state 
tables. The state tables show the state of a transport 
connection, the events that occur in the protocol, the actions 
taken and the resuitant state. 

The state tables describe only the operation of a single 
transport connection. They do not necessarily describe all 
possible combinations of sequences of events at transport 
and network service boundary, nor do they describe the 
exact mapping between TPDUs and NSDUs. 



A.2 Conventions 

A.2.1 Incoming events are represented in the state 
tables by their abbreviated name, as defined in table A.I . 

A.2.2 States are represented in the tables by their 
abbreviated name, as defined in table A.2. 

A.2. 3 The intersection of each state and event which is 
invalid is left blank. The action to be taken in this case shall 
be one of the following: 

a) for an event related to the transport service (i.e. 
coming from the TS-user), take no action; 

b) for an event related to a received TPDU, follow the 
procedure for treatment of protocol errors (see 6.22) if 
the state of the supporting network connection makes it 
possible; 

c) for an event falling into neither of the above 
categories (including those which are impossible by the 
definition of the behaviour of the transport entity or NS- 
provider), take no action. 

A. 2.4 At each intersection of state and event which is 
valid the state tables specify an action which may include 
one of the following: 



a) one action constituted of a list of any number of 
outgoing events (none, one, or more) given by their 
abbreviated name defined in table A.3 followed by the 
abbreviated name of the resultant state (see table A.2); 

b) conditional actions separated by a semi-colon (;). 
Each conditional action contains a predicate followed by 
a colon (;) and by an action as defined in a). The 
predicates are boolean expressions given by their 
abbreviated name and defined in the clauses related to 
the state tables of each class. Only the action 
corresponding to the predicate which is true shall be 
taken. 

A.2,5 The state tables also include 

a) informal comments giving explanatory materials; 

b) references to notes using the following notation: 
(note number); 

c) references to other actions defined in separate tables 
using the following notation: [action number]. 



A.3 Tables 

Table A.I specifies that names and abbreviated names of 
the incoming events, classified as TS-user events, NS- 
provider events or TPDU events. 

Table A.2 specifies the names and abbreviated names of 
the states. 

Table A.3 specifies the names and abbreviated names of 
the outgoing events classified as TS-provider events, NS- 
user events or TPDU events. 



A.4 State tables for classes and 2 

This clause provides a more precise description of a 
transport entity for a transport connection of class or class 
2. 

The description uses predicates defined in table A.4, and 
specific actions defined in table A.5. 

The description does not include a complete specification of 
the data transfer procedures but makes reference to the 
specification of the classes (see clause 8 and 10). Table 
A.6 gives the state automata for classes and 2. 
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Table A.1 - Incoming events 



Abbreviated name 


Category 


Name 


TCONreq 


TS-user 


T-CONNECT Request primitive 


TCONresp 


TS-user 


T-CONNECT Response primitive 


TDTreq 


TS-user 


T-DATA Request primitive 


TEXreq 


TS-user 


T-EXPEDITED DATA Request primitive 


TDlSreq 


TS-user 


T-DISCONNECT Request primitive 


NDISind 


NS-provider 


N-DISCONNECT Indication primitive 


NCONconI 


NS-prov'tder 


N-CONNECT Confirm primitive 


NRSTind 


NS-provider 


N-RESET Indication primitive 


CR 


TPDU 


Connection Request TPDU 


CC 


TPDU 


Connection Confirm TPDU 


DR 


TPDU 


Disconnect Request TPDU 


DC 


TPDU 


Disconnect Confirm TPDU 


AK 


TPDU 


Data Acknowledgement TPDU 


EA 


TPDU 


Expedited Data Acknow^ledgement TPDU 


DT 


TPDU 


Data TPDU 


ED 


TPDU 


Expedited Data TPDU 


ER 


TPDU 


TPDU Error TPDU 




RJ 


TPDU 


Reject TPDU | 



Table A.2 - States 



Abbreviated name 


Name 


WFNC 


Wait for networl< connection 


WFCC 


Wait for the CC TPDU 


WBCL 


Wait before releasing (wait for CC TPDU before sending the TPDU DR) 


OPEN 


Transport connection is open 


CLOSING 


Release in progress 


WFTRESP 


Wait for T-CONNECT response 


CLOSED 


Transport connection is closed 


WFNC-R 


Wait for networi< connection and reassignment in progress 


WFCC-R 


Wait for CC TPDU and reassignment in progress 


WBCL-R 


Wait before releasing and reassignment in progress 


OPEN-R 


Open and reassignment in progress 


OPEN-WR 


Open and wait for reassignment 


CLOSING-R 


Release in progress and reassiqnment in progress 


CLOSING-WR 


Release in progress and wait for reassignment 


WFTRESP-WR 


Wait for T-CONNECT response and wait for reassignment 


WBCL-WR 


Wait before releasing and wait for reassignment 


WBOC 


Wait before open complete (CC is unacknowledged) 


WBOC-WR 


Wait before open complete and wait for reassignment 


CLOSING BGC 


Wait before open complete and release in progress 


CLOSING BOC-WR 


Idem and wait for reassignment 


AKWAIT 


Waiting for acknowledgement of CC TPDU 


REFWAIT 


Waiting for frozen reference time 
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Table A.3 - Outgoing event 



Abbreviated name 


Category 


Name 


TCONind 


TS-provider 


T-CONNECT Indication primitive 


TCONconf 


TS-provider 


T-CONNECT Confirm primitive 


TDTind 


TS-provider 


T-OATA Indication primitive 


TEXind 


TS-provider 


T-EXPEDtTED DATA Indication primitive 


TDISind 


TS-provider 


T-DISCONNECT Indication pritnitive 


NDISreg^ 


NS-user 


N-DISCONNECT Re^uesLprimitive 


NRSTresp 


NS-user 


N-RESET Response primitive 


NCONreq 


NS-user 


N-CONNECT Request primitive 


CR 


TPDU 


Connection Request TPDU 


CC 


TPDU 


Connection Confirm TPDU 


DR 


TPDU 


Disconnect Request TPDU 


DC 


TPDU 


Disconnect Confirm TPDU 


AK 


TPDU 


Data Acknowledgement TPDU 


EA 


TPDU 


Expedited Data Acl<nowledgement TPDU 


DT 


TPDU 


Data TPDU 


ED 


TPDU 


Expedited Data TPDU 


ER 


TPDU 


TPDU Error TPDU 


RJ 


TPDU 


Reject TPDU 



Table A.4 - Predicates for classes and 2 



Name 


Description 


PO 


T-CONNECT request unacceptable 


Pi 


Unacceptable CR TPDU 


P2 


No network connection available 


P3 


Network connection available and open 


P4 


Network connection available and open in progress 


P5 


Class in class (class selected in CC) 


P6 


Unacceptable CC 


P7 


Class is class 2 


P8 


Acceptable CC 


P9 


Class 4 CR 


PIO 


Local choice 



Table A.5 - Specific actions for classes and 2 



Name 


Description 


[1] 


If the network connection Is not used by another transport 
connection assigned to it, it may be disconnected. (See 
6.1.3 note 3) 


f2] 


See 6.22 (receipt of an ER TPDU) 


[3] 


See data transfer procedures of the class 


[41 


See expedited data transfer procedure of the class 


[5J 


An N-RESET response has to be issued once for the 
network connection if the network connection has not been 
released. In class 0, an N-DISCONNECT request has to be 
issued. 


[6] 


The DC TPDU contains a SRC-REF field set to zero and a 
DST-REF field set to the SRC-REF of the DR TPDU 
received. 
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Table A.6 - State table for classes and 2 



State 
Event 


WFNC 


WFCC 


WBCL 

(Class 2 

only] 


OPEN 


CLOSING 

(Class 2 

only) 


WFTRESP 


CLOSED 


TCONreq 














PO: TDISind 
CLOSED; 

P2: 

NCONreq 

WFNC; 

P3:CR 

WFCC; 

P4: WFNC 


TCONresp 












CC 

OPEN 




TDTreg_ 








[31 OPEN 








TEXreq 


DOES NOT EXIST IN CLASS 1 








[4] OPEN 






1 


TDISreq 


[1] 
CLOSED 


not P7: 
NDISreq 

CLOSED; 

P7: WBCL 




P5: NDISreq 

CLOSED; 

P7:DR 

CLOSING 




DR 
CLOSED 




NCONconf 


CR WFCC 














NRSTind 




TDISind 

[1115] 
CLOSED 


[11[51 
CLOSED 


TDISind 

[1][5] 
CLOSED 


[1H5] 
CLOSED 


TDISind 

[1] [5] 
CLOSED 




NDISind 


TDISind 
CLOSED 


TDISind 
CLOSED 


CLOSED 


TDISind 
CLOSED 


CLOSED 


TDISind 
CLOSED 




CR ^ 


1 — ^ — --™, 






P9:OPEN 


P9: 
CLOSING 


P9: 
WFTRESP 


PI: DR(1) 

CLOSED; 

not PI: 

TCONind 

WFTRESP 


DR 




TDISind 




P5: (2); 




PIO: DC 
[61(5} 


CLOSED (4); 




[1! 
CLOSED 


[1] 
CLOSED 


P7:DC 
TDtSisd 
CLOSED 


[1] 
CLOSED 


TDISind 
CLOSED 


DC CLOSED 


DC 


DOES NOT EXIST IN CLASS (2) 


CLOSED 










P7:[1] 
CLOSED 






CC 




P8: TCONconf 

OPEN; 

P6 and P5: 

TDISind 

NDISreq 

CLOSED; 

P6 and P7: 

TDISind DR 

CLOSING 


P5 : (3) 
NDISreq 
CLOSED; 

P7:DR 
CLOSING 




CLOSING 




DR CLOSED 


AK 


DOES NOT EXIST IN CLASS 


2) 1 


CLOSED 


1 1 1 raiOPEN 1 CLOSING 1 




EA 


DOES NOT EXIST IN CLASS (2) 


CLOSED 


1 1 1 


[41 OPEN CLOSING 1 
TIN CLASS 2) 






ED 


DOES NOT EXIS 




CLOSED 








[41 OPEN 


CLOSING 






DT 








F31 OPEN 


CLOSING 




CLOSED 


ER 




TDISind 
11] CLOSED 


[1] CLOSED 


(2) 


(2) 




CLOSED 



(1) 

(2) 
(3) 
(4) 
(5) 



An ER TPDU should be sent in certain cases (see 6.6) 

If received it should be processed as a protocol error (see 6.22). 

A CR with class 2 has been sent and a CC class is received, 

If DC is not available (i.e. class only implemented) or SRC-REF is zero. 

This happens only when the preferred class of the CR TPDU received is class 4. 



73 



IS 13919: 1994 
ISO/IEC 8073 : 1992 



A.5 State tables for classes 1 and 3 

This clause provides a more precise description oi a 
transport entity for a transport connection of class 1 or 3. 

The description use the predicates defined in table A.7. 



Specific actions are defined in table A. 8 and specific 
additional notes are given in table A.9. 

The description does not include a complete specification of 
the data transfer but makes reference to the specification of 
the classes (see clauses 9 and 11). Table A. 10 gives the 
state automata for classes 1 and 3. 



Table A.7 - Predicates for classes 1 and 3 



Name 


Description 


PO 


T-CONNECT Request unacceptable 


PI 


No available network connection can be used for assignment 
or reassignment 


P2 


A network connection can be used for assignment or 
reassignment; the network connection opening is in 
progress 


P3 


A network connection can be used for assignment or 
reassignment; the network connection is open 


P4 


TTR timer has previously run out 


P5 


Local choice 


P6 


Initiator of the transport connection 


P7 


Unacceptable CR TPDU 


P8 


TWR is running 


P9 


Class 4 CR 


P10 


Class selected in CC is class or 2 



Table A.8 - Specific actions for classes 1 and 3 



Name 


Description 


[1] 


The network connection can be disconnected if not used by any transport 
connection assigned to it 


[2] 


Retransmit expedited data which are unacknowledged or which have been 
stored when waiting for reassignment (if any). If a RJ TPDU has been 
received, enable also data TPDU transmission (if any). If an ED was received, 
handle according to procedures for class if not a duplicate 


[3] 


Network connection can be disconnected if not used by any transport 
connection and was locally opened 


[4] 


Start TWR timer if not already running. Disable sending DT TPDUs until an RJ 
TPDU is received (see note 3) 


rsi 


Stop TWR timer 


[61 


Issue an N-RESET response it not already done 


[7] 


See data transfer procedure for the class 


[8] 


Start TTR timer if not already running. The sending credit is also set to zero in 
order not to send DT TPDUs until a RJ TPDU is received. 


[9] 


Stop TTR timer if running or remove information that TTR timer has run out 
(see notes 1 and 2) 


fioi 


Store information that TTR timer has run out (see note 1) 


[in 


Store request 


[121 


See state table appropriate to the class selected in the CC TPDU 


[13] 


close the network connection to which the transport connection is currently 
assigned, apply to all transport connections assigned to this network 
connection the procedure for processing NDISind and then process the TPDU 
reassignment. 


[14] 


The DC TPDU contains a SRC-REF field set to zero and a DST-REF field set 
to the SRC-REF of the DR TPDU received. 



NOTES 

1 This information is used by predicate P4. 

2 This action is not performed if the transport entity Is the responder or if neither reassignment nor 
resynchronization is in progress. 

3 The method of disabling transmission of DT TPDUs is a local matter. In class 3 for example, it may be 
effected by setting credit to zero. In class 1 , this may be effected by setting of a boolean indicator. * 
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Table A.9 - Specific notes for classes 1 and 3 



name 


description 


(1) 


Any TPDU except OR and CC having an unknown destination reference 


(2) 


CC TPDU having an unknown destination reference or a mismatched source reference 


(3) 


CR TPDU which is not duplicated but rejected. If the CR TPDU is duplicated, ignore it 


(4) 


Or send any DT or HD TPDU waiting for transmission or use N-DATA ACKNOWLEDGE 
request if available and selected (class 1 only) 


(5) 


Same as for (9) and issue a T-DISCONNECT indication 


(6) 


If the resultant state is CLOSED, the reference should be frozen except in the cases 
described in 6.18 


(7) 


An ER TPDU should be sent in the cases defined in 6.6 


(8) 


Receipt of a DC TPDU is a protocol error since DC cannot be used for reassignment. It 
is recommended to stop the TWR timer ([5]) and to consider the transport connection as 
released (CLOSED STATE) 


(9) 


Receipt of one of these TPDUs in this state is a protocol error. It is recommended to 
stop the TWR timer {[5]}, and send a DR TPDU and enter the closing state 


(10) 


Or a DR with mismatched source reference has been received 


(11) 


Receipt of CR in this state is only valid if the TPDU is received on a network connection 
to which the transport connection is not assigned. It is recommended to apply action 
f13l. 


(12) 


Receipt of this TPDU in this state is possible either on the network connection to which 
the transport connection is currently assigned or on another network connection (for the 
responder only). In the former case the action is as stated in the state table. In the 
latter case it is recommended to apply action [13]. 


(13) 


This happens only when the preferred class of the CR TPDU received is class 4. 
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Table A.10 - State table for classes 1 and 3 
(First part: connection - responder side) 



State 
Event 


CLOSED 


WFTRESP 


WFTRESP- 
WR 


WBCL-WR 


WBOC 


WBOC- 
WR 


CLOSING 
BOC 


CLOSING 
BOC-WR 


TDISreq 




DR 

CLOSED 

(6) 


WBCL-WR 




DR 

CLOSING 

BOC 


CLOSING 
BOC-WR 






TCONresp 




P10: (12); 

not PI 0: 

CC WBOC 


WBOC-WR 












NRSTind 




[4] [6] 

WFTRESP 

-WR 


(6] 

WFTRESP 

-WR 


[6] 
WBCL-WR 


[4] [6] 
WBOC- 
WR 


[6] 
WBOC- 
WR 


[4] [6] 
CLOSING 
BOC-WR 


[6] 
CLOSING 
BOC-WR 


NDISind 




t4] 

WFTRESP 

-WR 


WFTRESP 
-WR 


WBCL-WR 


14] 
WBOC- 
WR 


WBOC- 
WR 


[4] 
CLOSING 
BOC-WR 


CLOSING 
BOC-WR 


CR 


P7:DR 

{3 and 7) 

CLOSED 

(6); 

not P7: 
TCONind; 
WFTRES 

P 


P9: 
WFTRESP; 
notP9:(11) 


[51 
WFTRESP 


[5]DR 

CLOSED 

(6) 


P9: 
WBOC; 
not P9: 

(11) 


{5]CC 
WBOC 


P9: 
CLOSING 

BOC; 
notP9:(11) 


DR15] 

CLOSED 

(6) 


DR 


DC 
CLOSED 


P5: DC [14] 

(13) 

TDISind 

CLOSED 






TDISind 

DC 

CLOSED 

(6) (12) 


DC (5) 
TDISind 
CLOSED 


CLOSED 
(6) (12) 


[5] DC 

CLOSED 

(6) 


RJ or ED 


CLOSED 








OPEN [7] 
(12) 


[5] [2] 
RJ OPEN 


CLOSING 
(12) 


[5]DR 
CLOSING 


DC 


CLOSED 












CLOSED 


(8) 


First TPDU 
other than 
CR, DR, 
DC, ED, 
ER or RJ 


CLOSED 








OPEN [7] 




CLOSING 


(9) 


TWR 
time-out 






TDISind 

CLOSED 

(6) 


CLOSED 
(6) 




TDISind 

CLOSED 

(6) 




CLOSED 
(6) 


TDTreq 










[7] 
WBOC 


[11] 
WBOC- 
WR 






TEXreq 










[7] 
WBOC 


[11] 
WBOC- 
WR 






ER 










TDISind 

DC 

CLOSING 

BOC 




CLOSED 
(6) 
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Table A. 10 (continue) ~ State table for classes 1 and 3 
(Second part: connection initiator side) 



State 
Event 


CLOSED 


WFNC 


WFNC-R 


WFCC 


WFCC-R 


WBCL 


WBCL-R 


TCONreq 


PO: TDISind 
CLOSED; 
not (PO and 

PI) 
NCONreq 

WFNC; 

not (PO and 

P2): WFNC; 

not (PO and 

P3): CR 

WFCC 














NCONconf 




CR WFCC 


CR WFCC 




CR WFCC 




CR WBCL 


NRSTind 








P4: TDISind 
[6](6)[1] 
CLOSED; 

not P4: CR 
[6] [81 WFCC 




P4: |6] CLOSED 

[1]; 

not P4: CR [6] 
[8] WBCL 




NDISind 




Pi: 

NCONreq 

WFNC-R 

[8); 

P2: [8] 

WFNC-R; 

P3: CR [8] 

WFCC 


PI: 

NCONreq 

WFNC -R; 

P2: WFNC- 

R; 

P3:CR 

WFCC 


P4: TDISind 

CLOSED (6); 

(not P4) and 

Pi: [8] 

NCONreq 

WFCC-R; 

(not P4) and 

P2: [8] 

WFCC-R; 

(not P4) and 

P3: [8] CR 

WFCC 


PI: 

NCONreq 

WFCC-R; 

P2: WFCC- 

R; 

P3:CR 

WFCC 


P4orP5: [1 and 

9] (6) CLOSED; 

(not (P4 or P5)) 

and PI: [8] 

NCONreq 

WBCL-R; 

(not (P4 or P5)) 

and P2: [8] 

WBCL-R; 

(not (P4 or P5}) 

and P3: [8] CR 

WBCL 


P5: CLOSED 

(6) [9]; 

(not P5) and 

PI: 

NCONreq 

WBCL-R; 

(not P5) and 

P2: WBCL-R; 

(not P5) and 

P3:CR 

WBCL 


TDISreq 




[1] CLOSED 
(6) 


[1] CLOSED 
(6) [9] 


WBCL 


P5: 

CLOSED (6) 

[1 and 9]; 

not P5; 

WBCL-R 






DR 


(10) 

DC 

CLOSED 

(12) 






TDISind 

I1][9] 
CLOSED (6) 




[1][9] 
CLOSED (6) 




CC 


DR 
CLOSED 






Pl0:t12]; 

not P 10: 

TCONconf 

AK(4) OPEN 

[91 




Pi 0: [121; 
notPl0:DR 

[9] 
CLOSING 




(1) 


CLOSED 














(2) 


DR 
CLOSED 














TTR 
time-out 






TDISind 

[1] 
CLOSED (6) 


110] 


TDiSind 

[1] 
CLOSED (6) 


[10] 


[1] 
CLOSED (6) 


ER 








TDISind 

[1)(9] 
CLOSED (6) 




[11(9] 
CLOSED (6) 
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Table A.10 (concluded) - SttAe table for classes 1 and 3 
(Third part: OPEN and CLOSING states) 



State 


OPEN 


OPEN-R 


OPEN-WR 


CLOSING 


CLOSING-R 


CLOSING-WR 


Event 














NCONconf 




RJ[2] 
OPEN 






DR 
CLOSING 




TDISreq 


PS: CLOSING; 
not P8: DR 
CLOSING 


CLOSING-R 


CLOSING-WR 








NRSTind 


P6 and P4: (6) [6] 

[3] TDISind 

CLOSED; 

(P6 and not P4): 

[6] [2] [8] RJ 

OPEN; 

not P6; [4 and 6] 

OPEN 






P6 and P4: (6) 

[6] [3] CLOSED; 

P6 and not P4: 

[6][8]DR 

CLOSING; 

not P6: [4, 6] 

CLOSING 






NDISind 


P6 and P4: 


PI: NCONreq 




P6 and (P5 or 


P5: CLOSED 






TDISind CLOSED 


OPEN-R; 




P4): CLOSED 


(6): 






(6); 


P2: OPEN-R; 




(5); 


(not P5 and 






{P6 and not P4) 


PS: [2] RJ 




P6 and not (P4 


PI): NCONreq 






and PI: [8] 


OPEN 




or P5) and PI: 


CLOSING-R; 






NCONreq OPEN- 






[8] NCONreq 


(not P5) and 






R; 






CLOSING-R; 


P2: 






(P6 and not P4) 






P6 and not (P4 


CLOSING-R; 






and P2: [8] 






or P5) and P2: 


(not P5) and 






OPEN-R; 






[8] CLOSING-R; 


P3:DR 






(P6 and not P4) 






P6 and not (P4 


CLOSING 






and P3: [8] [2] RJ 






or P5) and P3: 








OPEN; 






[8]DR 








not P6: [4] 






CLOSING; 








OPEN-WR 






not P6: [4] 
CLOSING-WR 






RJ or ED 


P8: [5] [2] RJ 




RJ [5 and 2] 


P8: [5] DR 




DR[5] 




OP.EN; 




OPEN 


CLOSING; 




CLOSING 




not P8: [7] [9] 






not P8: [9] 








OPEN (12) 






CLOSING (12) 






TWR time-out 


TDISind (6) 
CLOSED 




TDISind (6) 
CLOSED 


CLOSED (6) 




CLOSED (6) 


DR 


P8: TDISind DC (6) 




TDISind DC 


P8: [5] DC (6) 




[5] CLOSED 




[5] CLOSED; 




[5] 


CLOSED; 




(6) DC 




not P8: TDISind 




CLOSED (6) 


notP8: [3] [9] 








DC (6) [9] 






(€) CLOSED (12) 








CLOSED (12) 












DC 








P8: (8); 
not P8: [3] [9] 
CLOSED (6): 




(8) 


DT, AK, or EA 


[7] OPEN 




(5) 


CLOSING 




(9) 


TPDU 














TTR time-out 


[10] 


TDISind 

CLOSED [1] 

(6) 




[10] 


CLOSED 

[1]{6) 




TDTreq 


P8: [11] OPEN; 
not P8: [71 OPEN 


[11] 
OPEN-R 


[11] 
OPEN-WR 








TEXreq 


P8; [11] OPEN; 
not P8: [71 OPEN 


[11] 
OPEN-R 


[11] 
OPEN-WR 








ER 


TDISind 




TDISind 


CLOSED 




CLOSED 




DR CLOSING 




DR CLOSING 


(6) 




(6) 
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A.6 State tables for class 4 over CONS 

This clause provides a more precise description of a class 4 
Transport Connection. 

Tables A.11, A.12, A.13 give the predicates, actions and 
notes for class 4 respectively. 

Table A.I 4 is the state table for a class 4 transport 
connection. 

The following assumptions and notations are used: 

a} the state of -every network connection is l<nown as 
being open or opening (i.e. a NCONreq has been issued 
and the NCONconf is awaited); 

b) for each transport connection the transport entity 
maintains the set of network connections to which the 
transport is assigned. A network connection in this set is 
either in open or opening state; 

c) when an N-CONNECT confirmation. N-RESET 
indication or N-DISCONNECT indication is received this 
event is associated with the transport connection if the 
network connection belongs to the set; 

d) when an N-DISCONNECT is received, the network 
connection becomes jjnexisting and is therefore 
withdrawn from the set. When a NCONconf is received 
the state of the nc becomes "open"; 

NOTE - This is not shown by an explicit action in the state 
table. Conversely adding a network connection to a set and 
setting its state to 'opening" is shown by an explicit action. 

e) when the state goes back to CLOSED or REFWAIT 
state, it is assumed that all timers are stopped (if 
running), the count is set to zero and the set becomes 
empty; 



f) when a TPDU is received the network connection on 
which it has been received is assumed to be known; 

g) the variable "current-nc" is used to designate either 
the network connection on which a TPDU has been 
received or the network connection which has been 
chosen lor a new assignment (either an existing one or a 
new one which is created); 

h) the following variables are also used: 

local-rof: the reference (local) of the TC is chosen 
when sending the CR or when accepting a CR; 

remote-ref: the reference of remote entity is initially 
set to zero and initialized when processing the CC 
except if the CC is ignored; 

SRC-REF: designates the corresponding field of the 
received TPDU; 

DST-REF: designates the corresponding field of the 
received TPDU; 

src-ref, dst-ref: designates the corresponding field of 
the sent TPDU; 

count: designates the number of times a TPDU has 
been sent (retransmissions); 

j) the data transfer phase is not completely described 
in the state table but refers to the main text; 

k) a spontaneous event called "new network connection 
assignment" has been introduced. It may occur at any 
time provided PI or P2 are true (see table A.11) and the 
remote ref is not zero (i.e. a CR TPDU has been 
received or a CC TPDU has been received and 
processed); 



m) when an N-RESET indication is received, 
RESET response is issued. 



an N- 



Table A.1 1 - Predicates for class 4 over CONS 



Name 


Description 


PO 


T-CONNECT Request is acceptable 


PI 


An assignment can be done to a suitable network connection 
(either open or opening) 


P2 


It is possible to open a new network connection 


P3 


Local choice 


P4 


A CR TPDU has never been sent 


P5 


The transport entity is the initiator and the set of network 
connections is now empty (i.e. a new assignment shall be 
done) or a new assignment is decided as a local choice 


P6 


Local choice not to perform a new assignment if the set of 
network connections is empty (for Closing state only) 


P7 


Count = maximum 


P8 


Acceptable CR TPDU 


P9 


Acceptable class 4 CC TPDU 


PIO 


Unacceptable class 4 CC TPDU 


P11 


CC TPDU not specifying class 4 
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Table A.12 - Specific actions for class 4 over CONS 



Name 


Description 


[0] 


Set relerence timer 


[1] 


Count = count + 1 


[2] 


Count = 


13] 


Set retransmission timer 


[4] 


Stop retransmission timer if running 


[5] 


Set window timer 


[6] 


Stop window timer if running 


[7] 


Set inactivity timer 


[8] 


Stop inactivity timer 


[9] 


Set initial credit for sending according to the received CR/CC TPDU 


[10] 


Set initial credit for controlling reception according tfie tlie sent CR/CC TPDU 


[111 


Send the CR TPDU if there is a networl< connection in the open state in the set 


[12] 


Add the current network connection to the set, if not already included 


[13] 


The current network connection is now in opening state 


[14] 


Send the CC TPDU if a network connection in the open state is in the set 


[15] 


Send the DR TPDU if a network connection in the open state is in the set. This DR TPDU 
is sent with SRC-REF = iocal-ref and DST-REF = remote-ref (may be zero) 


[16] 


Send the DR TPDU if a network connection in the open state is in the set. The DR TPDU 
is sent with SRC-REF = and DST-REF = remote-ref 


[17] 


Send a TPDU according to data transfer procedure 


[18] 


See state table of the class specified in the CC TPDU (refer to data transfer) 


• [19] 


See state table of the class (refer to release procedure): send a DR TPDU if the class is 
not 0. othenwise issue an N-DISCONNECT request 


[20] 


Store request and exercise flow control to the user 


[21] 


Send a DR TPDU with SRC-REF field sat to zero 


[22] 


Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to zero 
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Table A.13 - Specific notes for class 4 over CONS 



Name 


Description 


(1) 


Not possible as no set o1 Network Connections is associated with this transport connection 


(2) 


It is also possible to remain in the same state (Tl is still running) until 

- a CC TPDU is received which performs a new assignment; 

- a new assignment is tried (spontaneous event); 

- Tl runs out and the count is equal to the maximal value 


(3) 


No new assignment was possible: if the set is empty, the transport entity waits until a new 
assignment is received, or can be locally performed (spontaneous event) 


(4) 


It is also possible to perform a new assignment. (This may be done in triggering the event 
"new network connection assignment") 


(5) 


Not a duplicated OR TPDU. If the CR TPDU is duplicated, ignore it 


(6) • 


Since a new network connection is now assigned, it is recommended that the appropriate 
TPDU be sent on this network connection (if open) in order to make the remote entity 
aware of this assignment. It is also possible to allow the normal retransmission 
procedures to cause the TPDU to be sent; however, the first TPDU available for sending 
should be sent on the new network connection 


(7) 


As a local choice it is also possible to apply the following: 
fOl, TDISind, REFWAIT 


(8) 


Association to this transport connection is carried out regardless of the SRC-REF field, if 
the SRC-REF is not zero, a DC TPDU is sent back 


(9) 


At least an AK TPDU shall be sent if the transport entity is in the initiator in order to ensure 
that the responder will complete its three-way handshake 


(10) ■ 


If association has been made, and DST-REF is zero, then the DC TPDU contains a SRC- 
REF field set to zero 


(11) 


If the CLOSING state has been entered, coming from WFCC state, the remote-ref is zero. 
The SRC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU is retransmitted, it will 
be with DST-REF field set to zero) 


(12) 


If the CLOSING state has been entered, coming from WFCC state, the remote-ref (which 
is zero) shall be set with SRC-REF in order to comply with the release procedure of the 
negotiated class 


(13) 


The DR TPDU may be either repeated immediately or when Tl will run out 


(14) 


If the set is empty, this event may be used as a criteria for triggering the event "new 
network connection assignment" 


(15) 


Previously stored T-DATA or T-EXPEDITED DATA requests are ready for processing 
according to data transfer procedures 


(16) 


See data transfer^rocedures 


(17) 


When an N-RESET INDICATION is received, an N-RESET RESPONSE has to be issued 
once independent of the state automata 
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Table A. 14 - Class 4 connection/disconnection over CONS 






State 
Event 


REFWAIT 


CLOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


TCONreq 




not PO: 

TDISind 

CLOSED; 

POandPl: 

[12,1,3,10 

and 11] 

WFCC; 
PO and not 
PI and P2: 
[13,12, 1.3 

and 10] 
NCONreq 

WFCC; 

PO and not 

P2: 

TDISind 
CLOSED 














TCONresp 












[3, 2, 1, 10 
and 14] 
AKWAIT 






TDISreq 






P4: 

CLOSED; 

(not P4) and 

P3: WBCL; 

(not P4) and 

(not P3) [4, 3, 

• 2,1 and 15] 

CLOSING 




[6, 8, 4, 3, 2, 
1 and 15] 
CLOSING 


[16] 
CLOSED 


[4, 3, 2, 1 

and 15] 

CLOSING 




NDISind 


(1) 


(1) 


P1:(12I 

WFCC; 

(not PI) and 

P2:I13and 

12] NCONreq 

WFCC; 

(not PI) and 

(not P2): [0] 

[2] TDISind 

REFWAIT 


P3: [0] 

REFWAIT; 
(not P3) 
and Pi: 

[12 and 11] 
WBCL; 
(not PS) 
and (not 
P1)and 
P2: [13 
and 12] 

NCONreq 
WBCL; 
(not P3) 
and (not 
PI) and 
(not P2): 
[0] 

REFWAIT 


PSandPI: 
[12 and 17] 

(6) OPEN; 
P5 and (not 
Pl)andP2: 
[13 and 12] 

NCONreq 

OPEN; 
P5 and (not 
P1) and (not 
P2): OPEN 

(3): 
not P5: 
OPEN 


WFTRESP 
(4) 


P5andPl: 
[12 and 14] 

(6) 

AKWAIT; 

P5 and (not 

Pl)andP2: 

[13 and 12] 

NCONreq 

AKWAIT; 

P5 and (not 

Pl)and 

(not P2): 

AKWAIT 

(3); 

not P5: 
AKWAIT 


P6: [0] 

REFWAIT; 

(not P6) and P5 

and PI: [12 

and 15] 

CLOSING (6); 

(not P6) and P5 

and (not PI) 

andP2:[13 

and 12] 

NCONreq 

CLOSING; 

(not P6) and P5 

and (not Pi) 

and (net P2): 

CLOSING (3); 

(not P6) and 

(not P5): 

CLOSING 


NRSTird 






(17) 


(17) 


(17) 


(17) 


(17) 


(17) 


TDTreq 
TEXreq 










(16) OPEN 




[20] 
AKWAIT 




NCONconf 


0) 


(1) 


CR 
WFCC (6) 


CR 
WBCL (6) 


[17] 
OPEN (6) 


WFTRESP 


CC 

ADWAIT (6) 


[15] CLOSING 
(6) 


New 

network . 
connection 
assignment 










PI: [12 and 
17] OPEN 

(6); 

(not PI ) and 
P2:[13and 

12] 

NCONreq 

OPEN 


PI: [12] 

WFTRESP 

(6); 

(not Pi) 

and P2: [13 

and 12] 

NCONreq 

WFTRESP 


PI: [12 and 

14] (6) 

AKWAIT; 

(not PI) 

andP2:[13 

and 12] 

NCONrecf 

AKWAIT 


PI: [12 and 15] 

(6) CLOSING ; 

(not PI) and 

P2: [13 and 12] 

NCONreq 

CLOSING 
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Table A.14- 


Class 4 connection/disconnection over CONS [concluded) 




State 


BEFWAIT 


CtOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


Event 


















Retrans- 






P7 and P3 [0] 


P7 and P3: 


P7: [6, 8, 3, 




P7: [3. 2, 1 


P7: [0] 


timer 






TDISind 


[0] 


2, 1 and 15] 




and 15] 


REFWAIT; 








REFWAIT; 


REFWAIT; 


TDISind 




TDISind 


notP7: [1. 








P7 and (not 


P7 and (not 


CLOSING 




(U) 


3 and 1 5] 








P3): [3, 2, 1 


P3): [3, 2. 1 


(14): 




CLOSING; 


(14) 








and 15] 


and 15] 


nolP7: (16) 




notP7:[1, 


CLOSING 








TDISind 


CLOSING 


(14) OPEN 




3 and 14] 










CLOSING 


(14); 






(14) 










(U): 


not P7: [1, 






AKWAIT 










not P7: [1,3 


3, and 11] 
















and 11] 


WBCL 
















WFCC 












Inactivity- 










[6, 4, 3, 2. 1 








timer 










and 15] 

TDISind 

CLOSING (7) 








Reference 


CLOSED 
















timer 


















CR 




notP8:[21] 






[12, 8 and 7] 


[12] 


[12 and 


[121 






CLOSED 






OPEN 


WFTRESP 


14] 


CLOSING 






(5); 










AKWAIT 


(13) 






P8: [9 and 


















12] 


















TCONind 


















WFTRESP 


















(5) 














CC 


DR 


DR 


P9: [12, 9, 2, 


P11:[19]; 


[12,17.8 






P11:[19] 




REFWAIT 


CLOSED 


4, 5, 7 and 

17] 

TCONconf (9) 

OPEN; 

P10:[12, 4, 3. 

2, 1 and 15] 

TDtSind 

CLOSING; 

P11:[18] 


not P1 1: 
[12,2,4,3, 

1 and 15] 
CLOSING 


and 7] (9) 
OPEN 






(12); 

not P1 1 : 

[12] 

CLOSING 

(11) 


ER 


REFWAIT 


CLOSED 


[0] TDISind 


[0] 


[12, 6, 8, 4, 




[12, 4, 3, 


[0] 








REFWAIT 


REFWAIT 


3, 2, 1 and 
15] TDISind 
CLOSING 




2, 1 and 

15 

TDISind 

CLOSING 


REFWAIT 


DR 


[22] 


[22] 


(8) TDISind 


(8)[0] 


DC(10)[01 


DC (10) 


DC(10)[0] 


[0] 




REFWAIT 


CLOSED 


[0] REFWAIT 


REFWAIT 


TDISind 
REFWAIT 


TDISind 
CLOSED 


TDISind 
REFWAIT 


REFWAIT 


DC 


REFWAIT 


CLOSED 












[0] 
REFWAIT 


EA 


REFWAIT 


CLOSED 






[12, 8 and 7] 
OPEN (16) 






[12] 

CLOSING 

(13) 


DT/AK/ED 


REFWAIT 


CLOSED 






[12, 8 and 7] 
OPEN (16) 




[12 and 7] 
OPEN (15) 


[12] 
CLOSING 














(16) 


(13) 
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A.7 State tables for class 4 over CLNS 

This clause provides a more precise description of a class 4 
transport connection wtien operating over CLNS. 

Tables A.15, A. 16, A.17 give the predicates, actions and 
notes for class 4 respectively. 

Table A. 18 is the state table for a class 4 transport 
connection when operating over CLNS. 

The following assumption and notations are used 

a) local-ref; the reference (local) of the TC is chosen 
when sending the CR or when accepting a CR; 

remote-ref; the reference of the remote entity is 
initiallv set to zero and initialized when processing 
the CC except if the CC is ignored; 



SRC-REF: designates the corresoonding field of the 
received TPDU; 

DST-REF: designates the corresponding field of the 
received TPDU; 

src-ref, dst-ref: designates the corresponding fields 
of the sent TPDU; 

count: designates the number of times a TPDU has 
been sent (retransmissions); 

b) the data transfer phase is not completely described 
in the state table but refers to the main text; 

c) it is assumed that the networl< service is continuously 
available; 

The operations resulting from signalled inaccessibility of the 
network service are a local matter. 



Table A.15 - Predicates for class 4 over CLNS 



Name 


Description 


PO 


T-CONNECT request is acceptable. 


P3 


Local choice. 


P7 


Count = maximum. 


P8 


Acceptable CR TPDU. 


P9 


Acceptable class 4 CC TPDU 



Table A.16 - Specific actions for class 4 over CLNS 



Nanfte 


Description 


fO] 


Set reference timer 


[1] 


Count = count + 1 


[21 


Count = 


[3] 


Set retransmission timer 


[41 


Stop retransmission timer if running 


[51 


Set window timer 


f61 


Stop window timer if running 


f71 


Set inactivity timer 


fsi 


Stop inactivity timer if running 


m 


Set initial credit for sending according to the received CR/CC TPDU 


[10] 


Set initial credit for controlling reception according to the sent CR/CC TPDU 


[15] 


Send the DR TPDU. This DR TPDU is sent with src-ref = local-ref and dst-ref = 
remote-ref (may be zero) 


[161 


Send the DR TPDU. The DR TPDU is sent with src-ref = and dst-ref = remote-ref 


[171 


Send a TPDU according to data transfer procedure 


[201 


Store request and exercise flow control to the user 


[21] 


Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to 
zero 


[22] 


Send a DC TPDU except if the SRC-REF field of the received DR TPDU is equal to 
zero 


[231 


Send a DR TPDU with src-ref = local-ref and dst-ref = SRC-REF in CC TPDU 
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Table A.17 - Specific notes for class 4 over CLNS 



Name 


Description 


(5) 


Not a duplicated CR TPDU. If the CR TPDU is duplicated, ignore it. 


(7) 


As a local choice it is also possible to apply the following [0], TDISind, REFWAIT. 


(8) 


Association to this Transport connection is done regardless of the SRC-REF field. If 
SRC-REF is not zero, a DC TPDU is set back. 


(9) 


At least an AK TPDU shall be sent if the transport entity is the initiator in order to 
ensure that the responder will complete its three-way handshake. 


(10) 


If association has been made, and DST-REF is zero, then the DC tpDU contains a 
src-ref field set to zero. 


(11) 


If the CLOSING state has been entered, conning from WFCC state, the remote-ref is 
zero. The SRC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU is 
retransmitted, it will be with the dst-ref field set to zero). 


(13) 


The DR TPDU may be either repeated immediately or when T1 will run out. 


(15) 


Previously stored T-DATA or T-EXPEDITED-DATA requests are ready tor processing 
according to data transfer procedures. 


(16) 


See data transfer procedures. 
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TableA.18 


- Class 4 con 


nection/disconnection over 


CLNS (1 of 2) 




STATE 


REFWAIT 


CLOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


EVENT 


















TCONreq 




not PO: 

TDISind 

CLOSED; 

PO: 

[1,3,10]CR 

WFCC 














TCONresp 












[3,2,1,10] 

CC 

AKWAIT 






TDISieq 






P3: 

WBCL; 
not P3: 
[4,3,2,1,15] 
CLOSING 




[6,8,4.3,2,1, 

15] 

CLOSING 


[16] 
CLOSED 


[4,3.2,1, 

15] 

CLOSING 




TDTreq 
TEXreq 










(16) 
OPEN 




[20] 
AKWAIT 




Retrar^s- 






P7 and P3: 


P7 and P3: 


P7: 




P7: 


P7: 


tim^r 






[0] 

TDtSind 

REFWAIT; 

P7and 

{not P3): 

[3,2,1,15] 

TDISind 

CLOSING; 

not P7: 

[1,3],CR 
WFCC; 


[0] 
REFWAIT; 

P7and 

(not P3): 

[3,2.1,15] 

CLOSING; 

not P7: 

[1.3],CR 

WBCL; 


[6,8,3,2.1.15] 

TDISind 

CLOSING; 

not P7: 

(16) 

OPEN; 




[3.2.1.15] 

TDISind 

CLOSING; 

not P7: 

[1,3],CC 

AKWAIT; 


[0] 
REFWAIT; 

not P7: 
[1,3,15] 
CLOSING 


inactivity- 
Timer 










[6,4.3,2.1,15] 
TDtSind 
CLOSING 
(7) 








Reference 

-timer 


CLOSED 
















CR 




not P8; 

[21] 

CLOSED; 

P8: 

[1,9.3] 

TCONInd 

WFTRESP 

(5): 






[8,7] 
OPEN 


WFTRESP 


CC 
AKWAIT 


CLOSING 
(13) 
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Table A.18 - Class 4 co 


nnectionMisconnection over CLNS (2 of 2) 






STATE 
EVENT 


REFWAIT 


CLOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


CC 


DR 
REFWAIT 


OR 
CLOSED 


P9: 

[9,2.4,5,7,17] 

TCONconf 

(9) 

OPEN; 

not P9: 
[4,3.2,1.23] 
TDISind 
CLOSING; 


P9: 

[2,4.3,1,15] 

CLOSING; 


[17.8.7] 

(9) 
OPEN 






P9: 

(11) 
CLOSING 


ER 


REFWAIT 


CLOSED 


[0] 

TDISind 

REFWAIT 


[0] 
REFWAIT 


[6,8.4,3.2.1,15] 

TDISind 

CLOSING 




[4.3,2.1.15] 

TDISind 

CLOSING 


0] 
REFWAIT 


DR 


[22] 
REFWAIT 


[22] 
CLOSED 


(8) 

[0] 

TDISind 

REFWAIT 


(8) 
[0] 
REFWAIT 


DC (10) 

[0] 

TDISind 

REFWAIT 


DC (10) 
TDISind 
CLOSED 


DC (10) 
[0] 

TDISind 
REFWAIT 


[0] 
REFWAIT 


DC 


REFWAIT 


CLOSED 












[0] 
REFWAIT 


EA 


REFWAIT 


CLOSED 






[8.7] 
OPEN (16) 






CLOSING 
(13) 


DT/AK/ED 


REFWAIT 


CLOSED 






[8.7] 
OPEN (16) 




[7] 

OPEN 
(15) (16) 


CLOSING 
(13) 
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Annex B 

(normative) 

Network connection management subprotocol 



6.1 Introduction 

The objectives of this annex are to 

a) Provide for more flexibility in the use of the network 
connections established between two cooperating 
transport entities, thus enlarging the field of application 
of the transport protocol as presently defined in the main 
body of this International Standard. In particular it allows 
for an optimization of the use of the network connections 
by allowing both transport entities at each end of a 
network connection to assign and reassign transport 
connections to a network connection; 

b) Allow more information to be sent explaining why a 
network connection is released in order to be able to 
optimize recovery: 

The protocol described in this annex is called the network 
connection management subprotocol (NCMS). 

The procedures defined in this annex are optional 
extensions to the main body of this International Standard. 



B.2 Scope 

The procedures specified in this annex are an extension of 
the basic procedure defined in the main body of this 
International Standard and therefore do not prevent 
communication between transport entities conforming to this 
International Standard {ISO/lEC 8073) with this annex and 
those conforming to this International Standard without this 
annex. 

The basic network connection management that is specified 
in the main body of this International Standard allows for 
assignment or reassignment of transport connections on an 
existing network connection by its owner, who is currently 
restrrcted to be the transport entity that initiated this network 
connection. This addendum describes the procedures 
necessary to extend this basic management to permit the 
peer transport entity (i.e. the acceptor of a network 
connection) to become also the owner of the network 
connection and consequently to be able to assign or 
reassign transport connections to it. 

When performing multiplexing of transport connection this 
feature allows a network connection to be fully shared, thus 
increasing the scope of the multiplexing classes of the 
transport protocol (i.e. classes 2, 3 and 4). 



In order to control the number of shared network 
connections that peer entities are willing to use 
simultaneously (one or more), a mechanism is provided to 
resolve collisions when simultaneous network connection 
establishments occur, especially in the case of recovery 
after network failure. 



B.3 Definitions 

For the purposes of this annex, the following definitions 
apply. 

NOTE - The definitions contained in this clause make use of 
abbreviations defined in clause B.4. 

B.3.1 owner (of a network connection): The transport 
entity that issued the N-CONNECT request leading to the 
creation of the network connection if the NCM TPDU is not 
used or the transport entity (possibly both) which is 
designated to have the right of performing assignment in 
accordance with the NC-RIGHT field of the NCM TPDU 
when the NCM TPDU is used (see B.6.2.2). 

NOTE - This definition extends the definition of the owner of the 
network connection given in 3.2.28. 

B.3.2 network connection reference (or nc- 
reference): An identifier which is associated with a network 
connection and used to resolve collisJons when network 
connections are reopened. 



B.4 Symbols and abbreviations 

B.4.1 Types of transport-protocol-data-units 

NCM TPDU Network connection management TPDU 

DIAG TPDU Diagnostic TPDU 

NCMC TPDUNetwork connection management 
confirmation TPDU 

The following TPDU is used by this annex and is defined by 
ISO/lEC 11570, Transport protocol .identification 
mechanism: 



UN TPDU 



Use of network connection TPDU 
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B.4.2 TPDU fields 

NC-REF Network connection reference (field) 

NC-TYPE Network connection type (field) 

NC-RIGHT Network right (field) 

LI Length indicator (field) 

NC-PREF Network connection preference (field) 

NC-COL Network connection collision indicator 

NC-REC Network connection recovery indicator 

The following fields of the UN TPDU are used by this annex 
and are defined by ISO/IEC 1 1 570: 



SHARE 
PRT-ID 

B.4.3 Timers 

TTR-NC 

TPD-NC 
TFR-NC 



Sharing option (field) 
Protocol identifier (field) 



Time to try to reopen a network 
connection using a given NC-REF 

Time to consider a given NC-REF as 
pending 

Time to consider a given NC-REF as 
frozen 



B.4.4^ Miscellaneous 



NCMS 

NSAP 
AA 



Network connection management 
subprotocol 

Network-sen/ice-access-point 

Assignment right to alt 



SA 
RA 
AFI 

IDI 

DSP 



Sender has assignment right 

Receiver has assignment right 

Authority and Format Identifier (of the 
NSAP address) 

Initial Domain Identifier (of the NSAP 
address) 

Domain specific part (of the NSAP 
address) 



B.5 Overview of the protocol 

NCMS allows for: 

a) identification of the protocol to be used on top of a 
given network connection; 

NOTE - The use of NSAP addresses-as it is defined is ISO/IEC 
7498-3 provides greater flexibility in distinguishing between OSI 
and non-OSi users of the network service. If however the use 
of NSAPs incurs unacceptable penalties, for example where 
each NSAP is charged for by the network. provider, then the 
protocol identification mechanism (see ISO/IEC 11570) is 
available. 

b) Explicit designation of the transport entity (or entities) 
which has the right to assign transport connection(s) to a 
specific network connection and is therefore considered 
as the (co-)owner of the network connection; 

c) Resolution of connection establishment collisions 
when a network connection is first established or 
recovered after failure. 

NCMS assumes the use of the network service defined in 
ISO/IEC 8348. 

When operating NCMS the transport entities use only the 
network service primitives listed in table B.I (the other 
network service primitives are used as defined in 5.2). 
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Table B.I - Network Service Primitives Used for NCMS Operation 



Primitives 


Parameters 


A/B/C 


N-CONNECT request 
indication 
response 
confirm 

N-DISCONNECT request 
indication 


Called address 
Calling address 
NS user-data 
QOS parameter set 
Responding address 
Receipt confirmation selection 

NS user-data 

Originator 

Reason 


A 
A 
B 
A 
A 
A 

C 
C 
A 



Key 

A: 

B: 
C: 



This parameter is used in accordance with the procedures specified in the main body of 

this International Standard. 

When operating NGMS this parameter is used in request and indication and in response 

and confirmation If the NCMC TPDU is used. 

This parameter may be optionally used when operating NGMS. 



B.6 Elements of procedure 

B.6.1 TPDU transfer 

The transport-protocol-data-units (TPDUs) defined tor this 
annex are listed in B.4.1. 

The transport entities shall transmit and receive the UN (see 
ISO/IEC 11570) and NCM TPDU in the NS-user data 
parameter of the N-CONNECT request and indication 
primitive only. 

The sending transport entity shall: 

a) Either not transmit any TPDU in the NS-user data 
parameter of the N-CONNECT request primitive; 

b) Or transmit the UN TPDU (see ISO/IEC 11570) 
followed by the NCM TPDU in the NS-user data 
parameter of the N-CONNECT request primitive. 

When used the DIAG TPDU is transmitted in the NS-user 
data parameter of N-DISCONNECT primitive. 

When used the NCMC TPDU is transmitted in the NS-user 
data parameter of N-CONNECT response and confirmation 
primitive. 

B.6.2 Network connection management 

B.6.2.1 General 

When the procedure described in 8.6.1 b) is used 



a) The sending transport entity shall use the procedure 
described below together with the procedure defined in 
the main body of this International Standard; 

b) The receiving transport entity shall 

1) either ignore the NCM TPDU and operate the 
procedure described in the main body of this 
International Standard; 

2) or recognize and process the NCM TPDU and 
therefore operate the procedure described below 
together with those defined is the main body of this 
International Standard. 

When a transport entity has processed an NCM TPDU 
received from a given NSAP [see B.6.2.1 b)2)] it shall 
process further NCM TPDUs received from the same 
NSAP. 



B.6.2.2 Assignment right 

When an N-CONNECT request primitive is issued by a 
transport entity to request the opening of a new network 
connection, the transport entity may choose whether or not 
to include the NCM TPDU in the NS-user data parameter of 
the primitive. The recipient may choose not to process the 
NCM TPDU and to operate the procedures defined in the 
main body of this International Standard instead. 

The owner(s) may use the network connection for assigning 
or reassigning transport connections with the following 
restrictions: 

a) a transport entity which is the owner of the network 
connection shall not assign a transport connection with a 
preferred class or 1 if its peer is also the owner of the 
network connection (see note 2); » 
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b) a transport entity which is the owner of the network 
connection can assign a transport connection with an 
alternative class or 1, but shall not, when receiving a 
CR TPDU proposing or 1 as an alternative class, 
select one of these classes (see note 3). 

A transport entity shall be designated the "owner" of a 
network connection according to the table B.2. 

Table B.2 - Determination of assignment rights 



Entity 
Event 


Network 

connection 

initiator 


Network 
connection 
responder 


No NCM sent 


Y 


N 


NCM sent but not processed 
Right = SA or AA 


Y 


N 


NCM sent but not processed 
Right = RA 


N 

(see note 

4) 


N 

(see note 

4) 


NCM sent and processed 
Rights SA 


Y 


N 


NCM sent and processed 
Right = RA 


N 


Y 


NCM sent and processed 
Right = AA 


Y 


Y 



Key Y: owner 

N: not owner 



NOTES 

1 The use of a network connection by a called transport entity to 
■ initiate new transport connections should only be made when the 

called transport entity is adequately assured of the true identity of 
the calling transport entity (i.e. there is tnjst in the calling NSAP 
identification provided by the Network Layer) or the data to be 
transferred is not sensitive. 

2 This gives the guarantee that transport connections of classes 
or 1 cannot be opened simultaneously at both ends of a network 

connection. 

3 This allows a transport entity which has sent the NCM TPDU to 
stilt propose classes or 1 as an alternative class. If the peer 
transport entity has not processed the NCIVi TPDU it may still select 
class or class 1 . 

4 Use of NC-RIGHT with the NCM TPDU allows explicit control of 
assignment fights whilst also permitting both entities to be able to 
recover a failed network connection. This is not possible when the 
NCM is used. 

Provided that the restriction stated in B.6.2.2 a) and B.6.2.2 
b) are respected, both transport entities at each end of the 
network connection shall loilow the procedures delined in 
the main body of this International Standard, except that the 
owner of the network connection is defined as in B.6.2.2. 



NOTE - The transport protocol defined in the main body of 
this International Standard makes use of the definition of 
owner of a network connection for defining the entity which 
can perform assignment and reassignment. 

B.6.2.3 Network connection reference (nc-reference) 
management 

When a transport entity elects to use the NCM TPDU it shall 
keep track of the nc-references used in the NCM TPDUs 
sent or received in the NS-user data parameter of the N- 
CONNECT request or indication primitives. 

An nc-reference is associated with 

a) the pair of NSAPs addresses involved in the network 
connection on which the NCM TPDU has been 
transferred; 

b) the source of the allocation: the nc-reference has 
been remotely or locally allocated. 

The nc-reference is exchanged as the NC-REF 
parameter of the NCM TPDU. The NC-TYPE parameter 
of the NCM TPDU indicates the source of allocation: 

1) NC-TYPE set to NEW indicates a new nc- 
reference allocated by the sender of the NCM TPDU, 

2) NC-TYPE set to MY indicates a recovery using 
an nc-reference previously allocated by the sender of 
the NCM TPDU, 

3) NC-TYPE set to YOURS indicates a recovery 
using an nc-reference previously allocated by the 
receiver of the NCM TPDU; 

NOTE - Use of the NC-TYPE MY permits the explicit distinction 
between the two cases where the NC initiator either has or has 
not received the N-CONNECT confinn. 

c) the state of the nc-reference which can be 

1) OPEN: There is one network connection 
associated with the nc-reference and for which an N- 
CONNECT confirm has been received or an N- 
CONNECT response sent, and no subsequent N- 
DISCONNECT primitive exchanged, 

2) OPENING: There is one network connection for 
which an N-CONNECT confirm is awaited and the 
nc-reference has never been previously in the OPEN 
state, 

3) RECOVER: There Is one network connection 
associated with the nc-reference for which an N- 
CONNECT confirm is awaited and the nc-reference 
has previously been in the OPEN state, 

4) PENDING: There is no network connection 
associated with the nc-reference; 

d) the assignment right allocated for the use of the 
network connection associated witli the nc-reference. It 
can be 

1) my-side: The local transport entity is the only 
owner of the network connection, * 
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2) remote-side: The remote transport entity is the 
only owner of the network connection, 

3) both-sides: Both the local and the remote 
transport entities are the owners of the network 
connection; 

NOTE - Due to the collision and recovery mechanisms, it is 
possible that different network connections - initiated either by 
the local or the remote transport entity - be consecutively 
associated to the same nc-reference. The assignment rights 
are attached with the nc-reference and remain unchanged 
independent of whichever transport entity is the initiator of the 
network connection currently used. 

e) The preference to be used in the collision resolution 
mechanism (see B.6.2.5), This value is equal to the 
value of the field of the last NCM TPDU sent and is only 
significant when an N-CONNECT confirm is awaited (i.e. 
the nc-reference is either in the OPENING or in the 
RECOVERY state). 

When an nc-reference which has been locally allocated 
is no longer needed, the nc-reference shall not be 
reused before a TFR-NC period of time. No information 
is associated with this frozen reference other than the 
TRF-NC timer and will be considered unknown if 
received in an NCM TPDU. 

NOTE - In order to prevent that, in collision cases, two nc- 
references have the same value, it is required to allocate values 
at random, for example based on the time of their allocation. 

B.6.2.4 Timers 

The network connection management procedure makes use 
of the following timers: 

a) the TTR-NC timer defines the period of time that 
shall not be exceeded when reopening a network 
connection associated with a given nc-reference after 
the receipt of an N-DISCONNECT indication in 
OPENING or RECOVERY state, TTR NC shall be less 
than TPD-NC by at least the sum of the maximum 
disconnection and maximum connection propagation 
delays of the network service; 

b) the TPD-NC timer defines the minimum time a 
transport entity shall maintain an nc-reference in the 
PENDING state. A value of 2 min is used for TPD-NC: 

c) the TFR-NC timer defines the minimum time that 
shall elapse before an entity may reuse a locally 
allocated nc-reference. A value of 2 min is used for 
TFR-NC. 

B.6.2.5 Association of a received NCM TPDU with a 
known nc-reference 

When an NCM TPDU is received according to B.6.1 c) and 
B.6.2 and processed (a transport entity may always elect to 
process or ignore an NCM TPDU), the NCM TPDU is 
associated with an existing nc-reference if one of the 
following holds: 



a) either the three following conditions are met: 

1) the reference number received in the NC-REF 
parameter is the same as the one stored; and 

2) the pair of NSAPs addresses in the N-CONNECT 
indication in which the NCM TPDU was received is 
the same as those stored with the reference; and 

3) the parameter received in the NCM TPDU 
indicates the same source of allocation as that stored 
with the nc-reference, as indicated in table B.3; 

Table B.3 - Matching source of nc-reference allocation 



Stored Source 
NC-TYPE 


Remote 


Local 


NEW 


S 


D 


YOUR 


D 


S 


MY 


S 


D 



Key 



S = Same allocation source 
D = Different allocation source 



b) or there is no nc-reference known by the transport 
entity corresponding to B.6.2.5 a)1) above and the 
following three conditions hold: 

1 ) the NC-TYPE parameter has the value NEW; 

2) there is an nc-reference, locally allocated, joining 
the same pair of NSAPs addresses, in OPENING 
state and having the assignment right defined as 
follows: 

- assignment right is "my-side" and the RIGHT 
field of the received NCM TPDU holds the value 
RA (receiver has assignment right); 

- or assignment right is "remote-sides" and the 
RIGHT field of the received NCM TPDU holds the 
value SA (sender has assignment right); 

- or assignment right is "both-sides" and the 
RIGHT field of the received NCM TPDU holds the 
value AA (assignment right to all); 

3) acceptance of both network connections would 
result in the establishment of more connections than 
the transport entity is prepared to support. 

An NCM TPDU which is not associated but carries a value 
different from NEW in the TYPE parameter has to be 
considered an error. 



B.6.2.6 Collision 

B.6.2.6.1 Collision cases 
A collision is detected when: 

a) an NCM TPDU is associated with a known nc- 
reference (see B.6.2.5) and; 

b) there is an N-CONNECT confirm perjding for the 
network connection used for the nc-reference. 
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NOTE - In other words a collision is an association with an nc- 
reference either In OPENING or RECOVERY state, 

B.6,2.6.2 Collision resolution mechanism 



B.6.2.6.2.1 Collision winner 

When a collision occurs, one of the two network 
connections (i.e. the one which is currently used for the nc- 
reference and the one carrying the NCM TPDU which is 
associated with the nc-reference) has to be disconnected. 

In general the state of the nc-reference determines which 
network connection shall be disconnected. 

However, in the following two cases; 

a) the NCM has been associated with an nc-reference 
in RECOVERY state according to B.6,2.5 a) and the 
TYPE parameter has a value different from NEW; 

NOTE - In this case both ends are Jn RECOVERY state. 



b) or the 
B.6.2.5b). 



NCM has been associated according to 



NOTE - In this case both ends are in OPENING state, 



TPDU shall, if accepting the incoming network connection, 
transmit an NCMC TPDU in the NS-user data parameter of 
the N-CONNECT response. 

NOTES 

1 The NCMC TPDU is sent only if 

a) The incoming network connection is accepted; and 

b) The received NCM TPDU has the TYPE field set to NEW; 
and 

c) The received NCM TPDU has the RIGHT field set to RA. 

2 This mechanism avoids possible useless freezing of resources 
(network connection) when the peer-entity ignores an NCM TPDU 
which gives exclusive assignment. 

If an N-CONNECT confirmation is received after having an 
NCM TPDU with RIGHT set to RA, which does not carry an 
NCMC TPDU, the initiator shall disconnect the network 
connection. 

NOTE - The absence of NCMC TPDU indicates that the peer-entity 
did not process the NCM TPDU. 



B.7 Protocol operation 



The following procedure shall be used to determine if the 
local transport entity is the collision winner or the collision 
loser. The local entity is the winner if 

a) the state of the nc-reference is OPENING and the 
local allocated nc-reference has a lower value (nc- 
reference to be treated as a 16-bit integer) than the nc- 
reference of the received NCM TPDU. In the case when 
both references are equal, both network connections are 
disconnected, i.e. refused, and both transport entities 
choose another nc-reference and try (eventually) again; 

b) the state of the nc-reference is RECOVERY and the 
preference attached to nc-reference is higher than the 
one contained in the NC-PREF field of the received 
NCM TPDU; 

c) the state of the nc-reference is RECOVERY and the 
preference attached to nc-reference is equal to the one 
contained in the NC-PREF field of the received NCM 
TPDU and either: 

1) the source of allocation of the nc-reference is 
local and the value of the NC-REC field of the first 
sent NCM TPDU (i.e. which had NC-TYPE = NEW) 
was "please do not recover", or 

2) the source of allocation of the nc-reference is 
remote and the value of the NC-REC field of the first 
sent NCM TPDU (i.e. which had NC-TYPE = NEW) 
is "please recover". 

B.6.3 NCM confirmation 

When an NCM TPDU has been sent with RIGHT set to RA 
the transport entity which receives and processes the NCM 



B.7.1 Receipt of an N-CONNECT indication 

The recipient of an N-CONNECT indication which either 
does not contain an NCM TPDU or contains an NCM TPDU 
which it chooses to ignore shall follow the procedures 
described in the main body of this International Standard, If 
the NCM TPDU is to be processed then the transport entity 
shall apply the procedure for association of NCM TPDU to a 
known "nc-reference (see B.6.2,5). If the NCM TPDU is 
associated then the transport entity shall apply either the 
procedure describe in B.7.3a) or B.7. 3b) or B.7. 4.2 b) or 
B. 7,4.3 c) or B. 7.4.2 or B.7, 5 depending upon the state of 
the nc-reference. Othenwise the procedure in B.7. 2 applies. 

B.7.2 Passive network connection establishment with 
NCM TPDU 

The transport entity may either decide to refuse the 
incoming network connection (i.e. issue an N- 
DISCONNECT request) or accept the network connection. 

If the transport entity elects to accept the network 
connection it shall 

a) issue an N-CONNECT response; if the RIGHT field 
of the received NCM TPDU contains the value RA the 
NCMC TPDU shall be transmitted in the NS-user data 
parameter of the N-CONNECT response; 

b) note the nc-reference and the pair of NSAPs; 

c) note that the nc-reference has been remotely 
allocated; 
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d) note the assignment rights as my-side if RA has 
been received in the RIGHT field of the NCM TPDU, as 
remote-side if SA has been received or both-sides if AA 
has bee received; 

e) put the nc-reference into the OPEN state and use it 
for assignment or reassignment if it is (one of) the 
owner(s). 

B.7.3 Active network connection establishment with 
NCM TPDU 

The transport entity, which elects to use the NCfvIS 
procedure when opening a network connection shall send 
an N-CONNECT request with the UN TPDU (see tSO/lEC 
11570) and NCM TPDU contained in the NS-user data 
parameter. The NCM TPDU parameters are set as follows: 

- NC-REF contains the selected reference which shall 
neither be used for any other network connection 
between the same pair of NSAPs nor frozen; 

- NC-TYPE is set to NEW; 

- NC-RIGHT is set to SA, RA, or AA; 

- NC-PREF is set to low, medium or high according to 
the preference of the initiator to keep this connection in 
case of collision. 

NOTE - The selection of this value can be based on the 
knowledge of the correspondence between the expected QOS, 
the cost when reverse charging is used and other optimization 
considerations. 

The initiator shall store the nc-reference together with the 
pair of NSAPs to be joined by the network connection being 
established, the value of the NC-PREF parameter sent, the 
ownership of the network connection and the source of the 
nc-reference (locally allocated in this case). 

The state of the nc-reference shall be set to OPENING. 

The initiator shall wait for an N-CONNECT confirm to 
complete the establishment. If the assignment rights are 
"remote side" (i.e. an NCM TPDU with the RIGHT 
parameter having the value RA was sent) the received N- 
CONNECT confirm shall contain an NCMC TPDU in its user 
data parameter otherwise the transport entity shall 
disconnect the network connection. If one of the following 
cases occurs, the initiator shall perform the action specified: 

a) if an NCM TPDU is received and associated 
according to B.6.2.5b) (TYPE = NEW) the transport 
entity shall apply one of the following: 

1) if the local transport entity is the winner (see 
B.6.2.6.2) the incoming network connection is 
disconnected (i.e. an N-DISCONNECT request is 
sent in response to the incoming N-CONNECT 
indication) and the nc-reference remains in the 
OPENING state; 

2) if the local entity is the loser (see B.6.2.6.2) the 
network connection which was local opened is 



disconnected and the incoming network connection 
is accepted (i.e. an N-CONNECT response is 
issued). If the received NCM TPDU contains the 
value RA in its RIGHT field the NCMC TPDU shall be 
transmitted in the NS-user data parameter of the N- 
CONNECT response. The nc-reference which has 
been locally allocated is frozen for a TFR-NC period 
of time (and then released) and the transport entity 
keeps track of the nc-reference contained in the NC- 
REF parameter of the incoming NCM TPDU as 
remotely allocated and in OPEN state. The network 
connection is considered as open and ready for use 
as described in the main body of this International 
Standard, according to the assignment rights. 



Any transport connections assigned to 
disconnected connection shall be reassigned: 



the 



b) if an NCM TPDU is received with a TYPE parameter 
different from NEW and is associated, the transport 
entity shall 

1) issue an N-DISCONNECT request for the 
network connection for which the N-CONNECT 
confirm is awaited; 

2) respond to the incoming N-CONNECT indication 
by an N-CONNECT response; 

3) place the nc-reference in the OPEN state and 
consider the network connection as ready for 
assignment or reassignment according to the 
assignment rights; 

c) if an N-DISCONNECT indication is received, the 
transport entity may decide either to give up or try to 
reopen a network connection by issuing an N- 
CONNECT request containing an NCM TPDU (see 
B.6.1.2 and B.6.2) which is a copy of the previously sent 
NCM TPDU, except that the NC-PREF parameter may 
be different. The decision whether a new network 
connection has to be opened or not is a local matter 
subject to the following constraints: 

1) when the first N-DiSCONNECT indication is 
received, the entity shall start its TTR-NC timer and 
stop it when receiving the corresponding N- 
CONNECT confirm or N-CONNECT indication 
carrying an NCM TPDU which is associated and 
processed as described above. When the timer runs 
out the transport entity shall not try to open a network 
connection again if a new N-DISCONNECT 
indication is received; 

2) if the network connection is intended to be used 
for transport connections allowing recovery, the 
network connection has to be reopened in 
accordance with the agreed upon quality of service 
of the supported transport connection(s). 

When recovery is not performed or has stopped (i.e. 
a new N-DISCONNECT is received and TTR-NC has 
run out) the nc-reference of the network connection 
is placed in a PENDING state for a TPD-NC period 
of time. During this period the transport entity may 
receive an incoming NCM TPDU having this nc- 
reference (see B. 7.4.3). 
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B.7.4 Network connection recovery 

B.7.4.1 Receipt of an N-DISCONNECT indication 

When a network connection which was established using 
NCiVIS is disconnected (i.e. an N-DISCONNECT is 
received) the transport entity shall either 

a) elect not to reopen the network connection, place the 
nc-reference in the PENDING stale for a TPD-NC period 
of time, and apply the procedure described in B. 7.4.3; or 

b) attempt to reopen the network connection by 
following the procedure described in B. 7.4.2. 

Alternative b) is subject to the same constraints as 
described in B.7.3c). 

In all cases the transport entity shall apply the procedure 
corresponding to the receipt of an N-DISCONNECT 
indication to all transport connections assigned to the 
network connection. 



B.7.4.2 Active recovery procedure 

The transport entity shall open a network connection by 
putting the nc-reference into the RECOVERY state and 
sending an NCM TPDU in the NS-user data parameter of 
the N-CONNECT request according to B.6.1c) and B.6.2 
with the following parameters: 

a) NC-REF is set to the value of the nc-reference 
associated with the network connection; 

b) NC-TYPE is set to MY if the nc-reference was locally 
allocated, to YOURS if the nc-reference was remotely 
allocated; 

c) NC-PREF is set to the desired value (see B.7.3); 

d) NO-RIGHT may take any value; 

NOTE - NC-RIGHT is not significant in an NCM TPDU 
performing recovery. 

e) NC-REC is set to the desired value. 

The transport entity shall then apply one of the following: 

a) if an N-DISCONNECT is received apply B.7.4.1; 

b) if an NCM TPDU with type NEW is received and 
associated the incoming network connection is rejected; 

c) if an NCM with type different from NEW is received 
the collision winner is determined according to B.6.2. 6.2 
and: 

1) it the transport entity is the winner the incoming 
network connection is rejected, or 

2) if the transport entity is the loser the incoming 
network connection is accepted (i.e. send an N- 



CONNECT response), the nc-reference is placed in 
the OPEN state and is ready for use according to the 
assignmer.t rights. The network connection for which 
an N-CONNECT confirm was awaited is 
disconnected by issuing an N-DISCONNECT 
request. 

B.7.4.3 Passive recovery procedure 

If an N-CONNECT indication is received which carries an 
NCM TPDU, which is associated to the nc-reference, the 
transport entity shall send an N-CONNECT response (with 
an NCMC TPDU in the NS-user data parameter if the 
received NCM TPDU is of type NEW and has the right field 
set to the value RA) and put the nc-reference into the OPEN 
state and consider it as ready for assignment according to 
the assignment rights. 

If the TPD-NC timer expires and if the nc-reference was 
remotely allocated, then the transport entity does not keep 
track of it any longer; if the nc-reference was locally 
allocated, then the transport entity shall not reuse the 
reference until a TFR-NC period of time has elapsed. 

B.7.5 Remotely initiated recovery 

When a transport entity receives an NCM TPDU which is 
associated with an nc-reference in OPEN state if shall 

a) accept the incoming network connection and issue 
an N-CONNECT response; if the received NCM TPDU is 
of type NEW and has the RIGHT field set to RA, the 
NCMC TPDU shall be transmitted in the NS-user data 
parameter of the N-CONNECT response; 

b) issue an N-DISCONNECT request for the network 
connection which was associated with the ncreference; 

c) apply to all transport connections assigned to this 
network connection the procedure defined in the main 
body of this International Standard for processing an N- 
DISCONNECT indication. 



B.7.6 Optimization principles 

B.7.6.1 Use of the NC-REC indicator 

Although the recovery protocol is symmetrical, it should be 
noted that a transport entity is always allowed not to initiate 
recovery by putting the nc-reference into the PENDING 
state. 

NOTE - Not initiating recovery is equivalent to having a value of 
zero for the TTR-NC timer. 

In order to avoid unnecessary recovery being performed or 
recovery being delayed the NC-REC field of the NCM TPDU 
should be set as follows: 

a) (please do not recover): indicates that the sender 
does not rely on recovery being performed by the 
receiver, and intends to recover even if not required for 
its own need; 
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b) 1 (please recover): indicates that the sender expects 
a recovery to be done by the receiver, and does not 
intend to recover if it does not need it 

When the nc-reterence is in the OPEN state, the NC-REC 
field of the associated NCM TPDU gives both entities a view 
of the recovery intention of the partner. 

When a transport entity has to initiate recovery, i.e. an N- 
DISCONNECT indication has been received in OPENING or 
RECOVERY state and TTR-NC has not run out it is 
recommended that 

a) if the entity has received an NCM TPDU with the NC- 
REC field set to "please recover", it should try to recover 
even when this is not necessary for its own assignment 
needs; 

b) if the entity has received an NCM TPDU with the NC- 
REC field set to "please don't recover", it should not 
initiate recovery if this is not required for its own 
assignment needs; 

c) if the entity has sent an NCM TPDU with the NC- 
REC field set to "please don't recover", it should initiate 
recovery even if not required for its own assignment 
needs; 

d) if the entity has sent an NCM TPDU with the NC- 
REC field set to "please recover", it should not initiate 
recovery if not required for its own assignment needs. 

NOTE - As a local choice, it is possible to implement a 
symmetrical recovery mechanism by setting the NC-REC field 
to the value "please recover' and initiating recovery even 
though not required for the local assignment needs. 



B.7.6.2 Use of NS-user 
DISCONNECT primitive 



data parameter in N- 



The reason code in the N-DISCONNECT primitive does not 
adequately specify enough information to completely 
optimize the connection recovery mechanisms since the 
values defined in the network service (ISO/IEC 8348) do not 
distinguish between the cases where recovery is desirable 
immediately or not and do not provide adequate diagnostic 
information. Thus the NS-user data parameter of the N- 
DISCONNECT request may be used and may contain a 
DIAG TPDU. 

When 3 network connection is no longer needed, it is 
recommended that only the owner(s) may disconnect it, and 
put a DIAG TPDU with code 1 into the NS-user data 
parameter of the N-DISCONNECT request primitive. 

B.7.7 Releasing a network connection 

Either entity may release a network connection at any time 
by issuing an N-DISCONNECT request, it is recommended 
to use the DIAG TPDU in order to optimize this procedure 
as described in B.7.6.2. 



If the remote transport entity has assignment rights the nc- 
rsference shall be placed in the PENDING state after the 
network connection has been released. 

)f the remote transport entity does not have assignment 
rights the nc-reference may, as a matter of local choice: 

a) be put in the PENDING state; or 

b) if locally allocated be frozen; or 

c) if remotely allocated be made unknown. 

B.8 Structure and encoding of TPDUs 

B.8,1 Validity 

Table B.4 specifies the TPDU valid for this annex. 
Table B.4 -TPDU codes 



Name 


Code 


NCM, network connection management 


0000 0010 


DIAG, diagnostic 


0000 0011 


NCMC, network connection management 
confirmation 


0000 0100 



B.8.2 Structure 

The structure is defined in 13.2. 

B.8.3 Network connection management (NCM) TPDU 
B.8.3.1 Structure 

12 3 4 5 6 



LI 



NCM 
0000 0010 



NC-REF 



NC-TYPE 



NC-PREF 



NC-COL 

NC-REC 

NC-RIGHT 



B.8.3.2 LI 

See 13.2.1. 

B.B.3.3 Fixed part 

The fixed part shall contain 

a) NCM : NCM TPDU code: 000 0010; 

b) NC-REF : the nc-reference; 

c) NC-TYPE : indicates the type of the nc- 

reference which is sent. NC- 
TYPE consists of bits 8 and 7 of 
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d) NC-PREF 



e) NC-COL 



f) NC-REC 



g) NC-RIGHT 



octet 5 and may have the value 
00 (NEW). 01 (MY) or 10 
(YOURS), Value 11 is reserved; 

indicates the preference the 
initiator has to keep the networi< 
connection in case of collision. 
NC-REF is bits 6-1 of octet 5: 

000000 : highest preference, 

000001 : medium, 

00001 1 ; lowest preference; 

indicates the collision algorithm 
to be used. NC-COL is bit 8 of 
octet 6. Only one value is 
defined (0): resolution of collision 
when N-CONNECT indication is 
received; 



indicates the 
optimization option, 
bit 7 of octet 6: 



recovery 
NC-REC is 



: please do not recover, 

1 : please recover; 

indicates the kind of right of use 
given by the entity to its peer. 
NC-RIGHT is bits 6-1 of octet 6; 

000001 : SA, 

000010 : RA, 

000011 ; AA. 



B.8.3.4 Variable part 

There is no variable part. 

B.B.4 Diagnostic (OIAG) TPDU 

This TPDU is only transferred in the NS-user data 
parameter of an N-DISCONNECT. It provides diagnostic 
information. Sending and/or processing this TPDU is 
optional. 

B.8.4.1 Structure 



LI 


DIAG 

0000 001 1 


CODE 



B.8.4.2 LI 

See 13.2.1. 



B.8.4.3 Fixed part 

The fixed part shall contain 

a) DIAG: DIAG TPDU code 0000 0011; 

b) CODE: indicates the reason for disconnecting the 
network connection. The following values shall be used: 

- Collision detection resolution 

1 - Network connection no longer needed 

2 - Unrecognized NC-REF (do not try to recover 

with this NC-REF) 

3 -Network connection cannot be accepted 

(temporary congestion) 

4 - A new network connection cannot be accepted 

again {iong-term congestion or shutdown in 
progress) 

B.8.4.4 Variable part 

There is no variable part. 

B.8.5 Networl< connection management confirm 
(NCMC) TPDU 

B.8.S.1 Structure 



LI 


NCMC 
0000 0100 



B.8.5.2 LI 

See 13.2.1. 

B.8.5.3 Fixed part 

The fixed part shall contain the NCMC TPDU code: 
0000 0100. 

B.8.5.4 Variable part 

There is no variable part. 

B.9 Conformance 



B.9.1 When initiating a network connection a transport 
entity shall either 

a) not use the NS-user data parameter of N-CONNECT 
request primitive and operate using the protocol of the 
main body of this International Standard on this network 
connection; or 
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b) include in the NS-user data parameter of Xhe N- 
CONNECT request a UN TPDU (see ISO/IEC 11570) 
with the PRT-ID field set to the value 01 followed by an 
NCM TPDU and operate the NCMS procedure together 
with those specified in . the main body of this 
International Standard. 



PRT-ID field set to the value 01 (see ISO/IEC 11570)] 
and NCM TPDUs are present; or 

c) operate using the protocol of the rtiain body of this 
International Standard but ignore the NCM TPDU if the 
UN [with the PRT-ID field set to the value 01 (see 
ISO/IEC 11570)] and NCM TPDUs are present. 



B.9.2 When processing a N-CONNECT indication, a 
transport entity shall either 

a) operate using the protocol of the main body of this 
International Standard if no user data is present or if it is 
not claimed that the implementation supports the NCMS 
procedure; or 

b) operate using the protocol of the main body of this 
International Standard together with the network 
connection management procedure if the UN [with the 



B.10 State Table 

The following state tables define the states of a network 
connection reference as maintained by a single transport 
entity obeying the procedure of this annex. Due to failures 
and recovceries of network connections this reference may 
over a period of lime be associated with many network 
connections, one at a time. When an NCM TPDU is 
received the association procedure (see B.6.2.5) is applied 
first. 



Table B.5 - Events 



Event 



NCMNEWrec 



NCMNOTNEWre 



NDISind 



Collision 



TPD-NCexp 



TTR-NRexp 



Local decision 



Any TPDU 



NCONconf 



Description 



An N-CQNNECT indication containing an NCM TPDU with NC-TYPE = NEW is received 



An N-CONNECT indication containing an NCM TPDU with NC-TYPE not NEW is received 



An N-DISCONNECT indication 



A collision in the opening state as a result of association as described in 6.3,5b) 
The timer TPD-NC expires 



The timer TTR-NC expires 



The transport entity may choose to initiate this transition 



Receipt of any TPDU on the network connection 



An C-CONNEGT confirmation 



Table B.6 - Actions 



Action 



NCONreq 



NCMNEW 



NCMNOTNEW 



NDISreq 



NCONresp 



III 



M. 



J3L 



[4] 



JSL 



I6L 



iZL 



M_ 



[91 



Description 



Issue an N-CQNNECT request to the network service 



Send an NCM TPDU with the NCONreq with NC-TYPE = NEW and locally allocated nc-reference 
Send an NCM TPDU with the NCONreq with NC-TYPE set to show the original source of allocation 



of the reference 



Issue an N-DISCONNECT request to the network service 



Issue an N-DISCONNECT response to the network service 



Start TPD-NC timer 



Start TTR-NC timer if not already running 



Freeze the nc-reference for TFR-NC if locally allocated 



The remotely initiated connection has been the winner. Re-assign any TCs from the loser and 
process the incoming NCM TPDU as an NCMNEW in the CLOSED state for the winning reference 

Stop TTR-NC if running otherwise remove information that it has expired 

Stop TPD-NC 



Record with the nc-reference that a TPDU has been received 



Store information that TTR-NC has expired 



If the received NCM TPDU has the RIGHT field set to the value RA. a NCMC TPDU is transmitted in 
the NS-user data parameter of N-CONNECT response 
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Table B.7 - Predicates 



Predicate 


Description 


PI 


Incoming network connection unacceptable or the local entity is the winner of a coliision 


P2 


Remote transport entity is not an owner of the network connection and local choice 


P3 


Local choice not to recover or TTR-NC has previously expired 


P4 


Local choice not to recover 


P5 


The remotely initiated network connection is the winner of collision resolution 


P6 


A TPDU has been received on a network connection associated with this nc-reference [see (7)] 


P7 


Assignment rights are "remote side" and N-CONNECT confirmation does not carry an NCMC TPDU 



Table B.8 - Notes 



Note 


Description 


(1) 


DIAG TPDU with CODE = may be sent 


(2) 


The new connection is retained and the old connection disconnected 


(3) 


Repeat the previous NCM except that NC-PREF may be different 


(4) 


This is a protocol error 


(5) 


Discard the "loser" after collision resolution 


(6) 


The incoming network connection is disconnected and the old one retained 



Table B.9 - States 



Note 


Description 


CLOSED 


Network connection is closed 


OPENING 


Network connection requested but not yet confirmed 


OPEN 


Network connection is open 


RECOVERY 


Attempting recovery of a failed network connection 


PENDING 


A non-owner of the network connection is waiting for recovery by the owner 
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Table B.10 — State Table 



State 
Event 


CLOSED 


OPENING 


OPEN 


RECOVERY 


PENDING 


NCMNEWrec 


PI: 

NDISreq 

CLOSED; 

not Pi; [9] 

NCONresp 

OPEN; 




P6: (4) 

NDISreq 

OPEN; 

not P6: [9] 

NCONresp 

NDISreq (2) 

OPEN; 


NDISreq (6) 
RECOVERY 


P6: (4) 
NDISreq 
PENDING; 
not P6: [9] 
NCONresp 
[6] OPEN; 


NCMNOTNEWrec 


(4) NDISreq 


NCONresp (2) 
NDISreq OPEN 


NCONresp (2) 
NDIS req OPEN 


PI: NDISreq 

0) 
RECOVERY; 

not PI: 
NCONresp 
NDISreq (2) 
(5) OPEN; 


NCONresp 
[6] OPEN 


Local decision 


NCMNEW 
OPENING 










NDISind 




Not P3: [2] 
NCMNEW (3) 
OPENING; 
P2 & P3: [3] 
CLOSED; 
(not P2) & 
P3:[1,5] 
PENDING; 


Not P4: 

NCMNOTNEW 
[2] 

RECOVERY; 
P2 & P4: [3] 
CLOSED; 
P4 & not P2: 
[1] PENDING; 


Not P3: 

NCMNOTNEW 

RECOVERY; 

P3:[l,5] 

PENDING; 




Collision 




P1: NDISreq (1) 
OPENING; 
not PI: 
NDISreq (2) 
[4,3] 
CLOSED 








TPD-NCexp 










[3] CLOSED 


Any TPDU 






[7] OPEN 






TTR-NCexp 




[8] OPENING 




[8] RECOVERS 


r 


NCONconf 




P7:[3] 
CLOSED; 
notP7: [5] 
OPEN; 




[5] OPEN 
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B.1 1 Diagram for NCMS protocol operation 

This clause provides some tutortial information by giving 
examples of collision cases (see B.11.1) and remotely 
initiated recovery (see B.1 1 .2). This clause is informative. 

B.11.1 Collision case 

B.11.1 .1 Both end detect a collision on OPENING state 
with TYPE = NEW 



NCONreq 
(NCM-NEW) 



NCONind 
(NCM-NEW) 






/ 



\ 



NCONreq 
(NCM-NEW) 



NCONind 
(NCM-NEW) 



The references are different but both ends have decided to 
associate the received NCM TPDU according to B. 6. 2.5b). 



B.11.1.3 The initiator detects a collision in OPENING state 
with TYPE different from NEW 

B.11.1.3.1 The other end is in RECOVERY state 



NCONreq 
(NCM-NEW) 



NCONind ^^ 
(NCM-YOURS) 



\ 



\ 



\ 



^- 



\ 



NCONind 
(NCM-NEW) 

NCONresp 

NDISind 

NCONreq 
(NCM-YOURS) 



B.1 1.1 .2 Both ends detect a collision in RECOVERY state 



NCONreq 
(NCM-NEW) 



NCONconf 



NDISind 



NCONreq 
(NCM-MY) 



NCONind ^^ 
(NCM-YOURS) 



/ 



\ 






N. 



/ 



X 



NCONind 
(NCM-NEW) 

NCONresp 



NDISind 



NCONreq 
(NCM-YOURS) 



NCONind 
(NCM-MY) 



The entitiy in OPENING state (left side) accepts the 
incoming network connection and disconnects the 
PENDING one. 

B.11. 1.3.2 The other end detects a collision in 
RECOVERY state 



NCONreq 
(NCM-NEW) 



NDISind ■ 

NCONreq 
(NCM-NEW) 

NCONind 



-.X- 



y 



NCONind 
(NCM-NEW) 

NCONresp 



NDISind 

NCONreq 
(NCM-YOURS) 

NCONind 
(NCM-NEW) 



Both entities will use the collision resolution algorithm and 
one of the two network connections will be disconnected. 



Both entities disconnect the network connection initiated by 
the entity on the left. 
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B.1 1 .2 Remotely in itiated recovery 



NCONreq 
(NCM-NEW) 



NCONconf 



NCONind ^ 
(NCM-YOURS) 



NCONind 
(NCM-NEW) 

NCONresp 



NDISind 



NCONreq 
(NCM-YOURS) 



NCONind 
(NCM-NEW) 
NCONresp ■ 



NCONind .^ 
(NCM-YOURS) 



NCONreq 
(NCM-NEW) 



NDiSind 

NCONreq 
(NCM-YOURS) 



The entity on the left detects an incoming networl< 
connection In OPEN state and disconnects the old 
connection. 



The entity on the left detects an incoming networif 
connection in OPEN state and disconnects the old 
connection. 
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Annex Ci) 

{normative) 
PICS Proforma 



C.1 General 

C.1.1 Symbols used 

Status symbols: 

M Mandatory. 

O Optional to implement. If implemented the feature may or may not be used. 

0.<n> Optional but support of at least one of the group of options labelled by the same numeral <n> in this PICS proforma 
is required. 

<index>: This predicate symbol means that the status following it applies only when the PICS states that the feature identified 
by the index is supported. In the simplest case, <index> is the identifying tag of a single PICS item. <index> may 
also be a Boolean expression composed of several indices. 

<tndex>:: When this group predicate is true the associated clause should be completed. 

Support symbols: 

Yes Supported. 

No Not supported. 

N/A Not applicable. 

C.I. 2 Instructions for completing the PICS proforma 

The main part of the PICS proforma is a fixed-format questionaire divided into a number of clauses. Answers to the 
questionnaire are to be provided in the rightmost column either by simply marking an answer to indicate a restricted choice 
(such as Yes or No) or by entering a value of a range of values or entering what action is taken. 



1) Copyright release for PICS proforma 

Users of this International Standard may freely reproduce the PICS profonna in this annex so that it can be used for its intended purpose and 
may further publish the completed PICS. 
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C.2 Identification 

C.2.1 Implementation identification 



Supplier 




Contact point for queries about tiie PICS 




Implementation Names{s) and Version(s) 




Other information necessary for full identification - 
e.g. name(s) and version(s) of machines and/or 
operating systems; System Name(s) 





NOTES 

1 Only the first three items are required for all implementations; other informat'on may be completed as appropriate in meeting the 
requirement for full identification. 

2 The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology (e.g. Type, Series, Model) 



C.2.2 Protocol Summary 



idantification of protccoi speciiicatlon 


ISO/iEC 8073:1992 (E) 

CCITT X.224 Reference Number: X.224 (1988) 


identification of Amendments and 
Corrigenda to this PICS proforma which 
have been completed as part of this PICS 


ISO/IEC 3073:1992 


Prctocoi V9rsion(s) supported 


Version 1 


Have any Exception items been required? No [ ] Yes [ ] 

(The answer Yes means that the implementation does not conform to ISO/IEC 8073:1992/CCITT X.224) 



Date of statement 
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A C.6,1 

C C.6.2 

C4L C.6.2 

CCT C.5 

DRCC C.I 4 

DRCR C.14 

DRDR CI 4 

D1 iCC C.13.1 

D1ICR C.13.1 

D11DR C.13.1 

D2ICC C.13.2 

D2ICR C.13.2 

D2IDR C.13.2 

D3ICC C.13.3 

D3ICR C.13.3 

D3!DR C.13.3 

D4ICC C.13.4 

D4ICR C.13.4 

D4IDR C.13.4 

IC C.1 1.1.; 

ICR C.11.2 

IR C.8 

iOCC C.11.3 

lOCR C.11.3 

lODR C.11.3 

lice C.1 1.4 

11CR C.1 1.4 

II DR C.1 1.4 

II DT C.1 1.4 

HER C.11.4 

I2CC C.11.5 

I2CR C.11.5 

I2DR C.11.5 

I2ER C.11.5 

I3CC C.1 1.6 

13CR C.1 1.6 

I3DR C.1 1.6 

I3DT C.1 1.6 

I3ER C.1 1.6 

I4AK C.1 1.7 

I4CC C.1 1.7 

I4CR C1 1.7 

I4DR C.11.7 

I4DT C.11.7 

t4ER C.11.7 



ISO C.5 

N C.7 

NAC C.I 5.1 

NEF C.15.4 

NC C.I 5.1 

NUC C.I 5.6 

NUF C.15.7 

OT C.I 7 

PE C.16.1 

PE4L C.16.1 

RC C.I 5.2 

RC4a C.15,2 

RN C.12.1.2 

ROA C.15.11 

RR C.I 6.2 

R4AKch C.I 2.2 

R4CCch C.I 2.2 

R4DCch C.I 2.2 

R4DRch C.I 2.2 

R4DTch C.I 2.2 

R4EAch C.I 2.2 

R4EDch C.12.2 

R4ERch C.12.2 

SER CIO 

SER4L CIO 

SN CIO 

ST C.10 

TA C.17 

TED c.15.5 

TS CI 5.3 

TOP C.9.1 

TOS C.I 5.3 

TIF C.9.2 

T1S C.15.3 

T2F c.9.3 

T2S C.15.3 

T3F C.9.4 

T3S c.15.3 

T4F C.9.5 

T4S c.15.3 

Ul CI 6.3 

UNED C.15.9 

UNRC C15.8 

USA CI 5.10 
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C.4 Based standard/recommendation conformance 



Does the implementation claim conformance to ISO/IEC 8073? 



Yes No 



Does the implementation claim conformance to CCITT X.2247 



Yes No 



C.5 General statement of conformance 



ISO 


Are all mandatory features of ISO/IEC 8073 implemented? 


Yes No 


CCT 


Are all mandatory features of X.224 implemented? 


Yes No 



Note - Answering No' to this question indicates non-conformance to the International Standard/Recommendation. 

C.6 Protocol implementation 

C.6.1 Annex B-NCMS 



index 




References 


Status 


Support 


A1 


Network connection management procedures 


Annex B 


O 


Yes No 



C.6.2 Classes implemented 



Index 


Class 


References 


Status 


Support 


CO 


Class 


14 


IS0:0.1 
CCT:M 


Yes No 


CI 


Class 1 


14 


C0:O 


Yes No 


C2 


Class 2 


14 


1S0:0.1 
CCT:0 


Yes No 


C3 


Class 3 


14 


C2:0 


Yes No 


C4 


Class 4 operation over CONS 


14 


C2:0 


Yes No 


C4L 


Class 4 operation over CLNS 


14 


IS0:C2:0 
CCT:N/A 


Yes No 
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C.7 NCMS functions 



Index 


Item 


References 


Status 


Support 


N2 


Network connection management 


B.6.2.1 





Yes No 


N3 


Diagnostic 


8.7.6.2, 
B.7.7 


O 


Yes No 


N4 


Active network connection recovery 


B.7.4.2 





Yes No 



The following is mandatory if the predicate is true 










Index 


Item 


References 


Status 


Support 


N5 


Passive network connection recovery 


B.7.4.3 


N2 OR N4: 
M 


Yes No 


N6 


Is an NCM TPDU with assignment right set to RA 
N-DISCONNECT request? 


always rejected with 


B.6.3 


O 


Yes No 



C.8 Initiator/responder capability for protocol classes 0-4 



Index 




References 


Status 


Support 


IR1 


Initiating CR TPDU 


14.5 a) 


0.2 


Yes No 


IR2 


Responding to CR TPDU 


14.5 a) 


0.2 


Yes No 



C.9 Supported functions 

C.9.1 Supported functions for class (CO::) 

The following f u nctions are mandatory if class is supported 



Index 


Function 


References 


Status 


Support 


T0F1 


Assignment to network connection when operating over CONS 


6.1.1 


M 


Yes 


T0F2 


TPDU transfer 


6.2 


M 


Yes 


T0F3 


Segmenting 


6.3 


M 


Yes 


T0F4 


Reassembling 


6.3 


M 


Yes 


T0F5 


Connection establishment 


6.5 


M 


Yes 


T0F6 


Connection refusal 


6.6 


M 


Yes 


T0F7 


Normal release when operating over CONS (implicit) 


6.7.1 


M 


Yes 


T0F8 


Error release when operating over CONS 


6.8 


M 


Yes 


T0F9 


Association of TPDUs with Transport connection when operating over 
CONS 


6.9.1 


M 


Yes 


T0F10 


Treatment of protocol errors when operating over CONS 


6.22.1 


M 


Yes 
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C.9.2 Supported functions for class 1 (C1 ::) 

The follovying functions are mandatory if class 1 is supported 



Index 


Function 


References 


Status 


Support 


T1F1 


Assignment to network connection when operating over CONS 


6.1.1 


M 


Yes 


T1F2 


TPDU transfer 


6.2 


M 


Yes 


T1F3 


Segmenting 


6.3 


M 


Yes 


T1F4 


Reassembling 


6.3 


M 


Yes 


T1F5 


Separation 


6.4 


M 


Yes 


T1F6 


Connection establishment 


6.5 


M 


Yes 


T1F7 


Connection refusal 


6.6 


M 


Yes 


T1F8 


Normal release when operating over CONS (explicit) 


6.7.1 


M 


Yes 


11 F9 


Association of TPDUs with Transport connections when operating 
over CONS 


6.9.1 


M 


Yes 


T1F10 


Data TPDU numbering (normal) 


6.10 


M 


Yes 


T1F11 


Expedited data transfer when operating over CONS (Network normal) 


6.11.1 


M 


Yes 


T1F12 


Reassignment after failure when operating over CONS 


6.12 


M 


Yes 


T1F13 


Retention and acknowledgement of TPDUs 
Retention until acknowledgement of TPDUs (AK) 


6.13.4.1 


M 


Yes 


T1F14 


Resynchronization 


6.14 


M 


Yes 


T1F1S 


Frozen references 


6.18 


M 


Yes 


T1F16 


Treatment of protocol errors when operating over CONS 


6.22.1 


M 


Yes 


The follov 


\i\r\g functions are optional if class 1 is supported 








Index 


Function 


References 


Status 


Support 


T1F17 


Concatenation 


6.4 





Yes No 


T1F18 


Expedited data transfer when operating over CONS (Network 
expedited) 


6.11.1 


O 


Yes No 


T1F19 


Retention and acknowledgement of TPDUs 
Confirmation of Receipt 


6.13.4.2 


notTlF20: 



Yes No 


T1F20 


Retention and acknowledgement of TPDUs 
Use of request acknowledgement 


6.13.4.3 


notTlFl9: 
O 


Yes No 
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C.9.3 Supported functions for class 2 (C2::) 

The following functions are mandatory if class 2 is supported 



index 


Function 


References 


Status 


Support 


T2F1 


Assignment to network connection when operating over CONS 


6.1.1 


M 


Yes 


T2F2 


TPDU transfer 


6.2 


M 


Yes 


T2F3 


Segmenting 


6.3 


M 


Yes 


T2F4 


Reassembling 


6.3 


M 


Yes 


T2F5 


Separation 


6.4 


M 


Yes 


T2F6 


Connection establishment 


6.5 


M 


Yes 


T2F7 


Connection refusal 


6.6 


M 


Yes 


T2F8 


Normal release when operating over CONS (explicit) 


6.7.1 


M 


Yes 


T1F9 


Error release when operating over CONS 


6.8 


M 


Yes 


T2F10 


Association of TPDUs with Transport connections when operating 
over CONS 


6.9.1 


M 


Yes 


T2F11 


Data TPDU numbering (normal) 


6.10 


M 


Yes 


T2F12 


Expedited data transfer when operating over CONS (Network normal) 


6.11.1 


M 


Yes 


T2F13 


Demultiplexing when operating over CONS 


6.15 


M 


Yes 


T2F14 


Explicit flow control (with) 


6.16 


M 


Yes 


T2F15 


Treatment of protocol errors when operating over CONS 


6.22.1 


M 


Yes 


T2F16 


Multiplexing when operating over CONS 


6.15 


M 


Yes 


The follow 


ring functions or elements of procedure are optional if class 2 is supporte 


d 






Index 


Function 


References 


Status 


Support 


T2F17 


Concatenation 


6.4 





Yes No 


T2F18 


Data TPDU numbering (extended) 


6.10 


O 


Yes No 


T2F19 


Explicit flow control (without) 


6.16 


O 


Yes No 
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C.9.4 Supported functions for class 3 (C3::) 

The follovying functions are mandatory if class 3 is supported 



Index 


Function 


References 


Status 


Support 


T3F1 


Assignment to network connection when operating over CONS 


6.1.1 


M 


Yes 


T3F2 


IPDU transfer 


6.2 


M 


Yes 


T3F3 


Segmenting 


6.3 


M 


Yes 


T3F4 


Reassembling 


6.3 


M 


Yes 


T3F5 


Separation 


6.4 


M 


Yes 


T3F6 


Connection establishment 


6.5 


M 


Yes 


T3F7 


Connection refusal 


6.6 


M 


Yes 


T3F8 


Normal release when operating over CONS (explicit) 


6.7.1 


M 


Yes 


T3F9 


Association of TPDUs with Transport connections when operating 
over CONS 


6.9.1 


M 


Yes 


T3F10 


Data TPDU numbering (normal) 


6.10 


M 


Yes 


T3F11 


Expedited data transfer when operating over CONS (Network normal) 


6.11.1 


M 


Yes 


T3F12 


Reassignment after failure when operating over CONS 


6.12 


M 


Yes 


T3F13 


Retention and acknowledgement of TPDUs 
Retention until acknowledgement of TPDUs (AK) 


6.13.4.1 


M 


Yes 


T3F14 


Resynchronization 


6.14 


M 


Yes 


T3F15 


Demultiplexing when operating over CONS 


6.15 


M 


Yes 


T3F16 


Explicit flow control 


6.16 


M 


Yes 


T3F17 


Frozen references 


6.18 


M 


Yes 


T3F18 


Treatment of protocol errors when operating over CONS 


6.22.1 


M 


Yes 


T3F19 


Multiplexing when operating over CONS 


6.15 


M 


Yes 


Tiie follov 


vinq functions are optional if class 3 is supported 








Index 


Function 


References 


Status 


Support 


T3F20 


Concatenation 


6.4 





Yes No 


T3F21 


Data TPDU numbering (extended) 


6.10 





Yes No 


T3F22 


Retention and acknowledgement of TPDUs 
Use of request acknowledgement 


6.13.4.3 


O 


Yes No 
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C.9.5 Supported functions for class 4 (C4 or C4L:: 

The following functions are mandatory 



Index 


Function 


References 


Status 


Support 


T4F1 


TPDU transfer 


6.2 


M 


Yes 


T4F2 


Segmenting 


6.3 


M 


Yes 


T4F3 


Reassembling 


6.3 


M 


Yes 


T4F4 


Separation 


6.4 


M 


Yes 


T4F5 


Connection establishment 


6.5 


M 


Yes 


T4F6 


Connection refusal 


6.6 


M 


Yes 


T4F7 


Data TPDU numbering (normal) 


6.10 


f^ 


Yes 


T4F8 


Retention and acknowledgement of TPDUs 
Retention until acknowledgement of TPDUs (AK) 


6.13.4.1 


M 


Yes 


14 F9 


Explicit flow control 


6.16 


M 


Yes 


T4F10 


Checksum 


6.17 


M 


Yes 


T4F11 


Frozen references 


6.18 


M 


Yes 


T4F12 


Retransmission on time-out 


6.19 


M 


Yes 


T4F13 


Resequencing 


6.20 


M 


Yes 


T4F14 


Inactivity control 


6.21 


M 


Yes 


The follov 


i/ing functions are mandatory if class 4 is operated over CONS 








Index 


Function 


References 


Status 


Support 


T4F15 


Assignment to network connection when operating over CONS 


6.1.1 


M 


Yes 


T4F16. 


Normal release when operating over CONS (explicit) 


6.7.1 


M 


Yes 


T4F17 


Association of TPDUs with Transport connections when operating 
over CONS 


6.9.1 


M 


Yes 


T4F18 


Expedited data transfer when operating over CONS (Network normal) 


6.11.1 


M 


Yes 


T4F19 


Multiplexing when operating over CONS 


6.15 


M 


Yes 


T4F20 


Demultiplexing when operating over CONS 


6.15 


M 


Yes 


T4F21 


Treatment of protocol errors when operating over CONS 


6.22.1 


M 


Yes 


T4F22 


Recombining when operating over CONS 


6.23 


M 


Yes 


The following functions are mandatory if class 4 is operated over CLNS 


Index 


Function 


References 


Status 


Support 


T4F23 


Transmission over CLNS 


6.1.2 


M 


Yes 


T4F24 


Normal release when operating over CLNS (explicit) 


6.7.2 


M 


Yes 


T4F25 


Association of TPDUs with Transport connection when operating over 
CLNS 


6.9.2 


M 


Yes 


T4F26 


Expedited data transfer when operating over CLNS (Network normal) 


6.11.2 


M 


^es 


T4F27 


Treatment of protocol errors when operating over CLNS 


6.22.2 


M 


Yes 
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The following functions are optional 



Index 



T4F28 



T4F29 



T4F30 



T4F31 



T4F32 



Function 



Data TPDU numbering (extended) 



Non-use of checksunn 



Concatenation 



Retention and acknowledgement of TPDUs 
Use of selective acknowledgement 



Retention and acknowledgement of TPDUs 
Use of request acknowledgement 



The following functions are optional if class 4 is operated over CONS 



Index 



T4F33 



References 



Status 



Support 



6.10 



6.17 



6.4 



6.13.4.4 



6.13.4.3 



Function 



Splitting and recombining when operating over CONS 



O 



O 



O 



Yes No 



Yes No 



Yes No 



Yes No 



Yes No 



References 



Status 



6.23 



O 



Support 
No 



Yes 
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CIO Supported TPDUs 

The following TPDUs and the parameters which constitute their fixed parts are mandatory if a corresponding predicate in tiie 
status column is true 



Index 


TPDUs 


References 


Status 


Support 


ST1 


CR 


supported on transmission 


13.1 


IR1:M 


Yes No 


ST2 


CR 


supported on receipt 


13.1 


IR2:M 


Yes No 


ST3 


CC 


supported on transmission 


13.1 


IR2:M 


Yes No 


ST4 


CC 


supported on receipt 


13.1 


IR1:M 


Yes No 


ST5 


OR 


supported on transmission 


13.1 


IR2:M 


Yes No 


ST6 


DR 


supported on receipt 


13.1 


IRl:M 


Yes No 


ST7 


DC 


supported on transmission 


13.1 


Cl OR C2 OR 03 OR 
C4 0RC4L;M 


Yes No 


ST8 


DC 


supported on receipt 


13.1 


CI OR C2 OR C3 OR 
C4 OR C4L:M 


Yes No 
Yes 


ST9 


DT 


supported on transmission 


13.1 


M 


ST10 


DT 


supported on receipt 


13.1 


M 


Yes 


ST11 


ED 


supported on transmission 


13.1 


C1 ORC2 0RC3 0R 
C4 OR C4LM 


Yes No 


ST12 


ED 


supported on receipt 


i3.r 


CI OR C2 OR C3 OR 
C4 OR C4L:M 


Yes No 


ST13 


AK 


supported on transmission 


13.1 


CI OR C2 OR C3 OR 
C4 OR C4L:M 


Yes No 


ST14 


AK 


supported on receipt 


13.1 


Cl ORC2 0RC3 0R 
C4 0RC4L:M 


Yes No 


ST15 
ST16 


EA 


supported on transmission 


13.1 


Cl ORC2 0RC3 0R 
C4 0RC4L:M 


Yes No 


EA 


supported on receipt 


13.1 


Cl OR C2 OR C3 OR 
C4 OR C4L:M 


Yes No 


ST17 


RJ 


supported on transmission 


13,1 
13.1 
13.1 


Cl OR C3-.M 


Yes No 


ST18 


RJ 


supported on receipt 


Cl 0RC3;M 

M 


Yes No 
Yes 


ST19 


ER 


supported on receipt 



State for which classes, if any, ER is supported on transmission 






Index 


Class 


- - 
Reference 


SERO 


Class 


6.2i:.1 
6.22-1 




SER1 


Class 1 




SER2 


Class 2 


6.22,1 




SER3 


Class 3 


6.22.1 




SER4 


Class 4 ovsr CONS 


6.22 1 
6.22.2 




SER4L 


Glass 4 over CLNS 


L. 



Slafi! 
O 
O 
O 
O 
O 
O 



Support 

Yes No 

Yes No 

Yes No 

Yes No 

Yes No 

j Yes No 
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The following TPDUs are mandatory it a corresponding predicate in the status column is true. 




Index 


TPDUs 


References 


Status 


Support 


SN3 


NCM 


supported on transmission 


B.8.1 


N2:M 


Yes No 


SN4 


NCM 


supported on receipt 


B.8.1 


N2:l\^ 


Yes No 


SN5 


DIAG 


supported on transmission 


B.8.1 


N3:M 


Yes No 


SN6 


DIAG 


supported on receipt 


B.8.1 


N3:M 


Yes No 


SN7 


NCMC 


supported on transmission 


B.8.1 


SN4 AND NOT N6:M 


Yes No 


3N8 


NCMC 


supported on receipt 


B.8.1 


P1:M 


Yes No 



PI: SN3 and the only supported value In IC5 is "receiver". 



C.1 1 Supported parameters of issued TPDUs 

C.1 1 .1 Supported parameters for NCMS (A1 ::) 

C.1 1.1.1 NCM TPDU (SN3::) 

What are the allowed values of the following parameters for a NCM TPDU? 



index 


Supported parameters 


References 


Allowed values 


Supported values 


101 NC-type 


B.8.3.3 c) 


New, My, Yours 




iC2 


NC-prsference 


B.8.3.3 d) 


Highest, Medium, Lowest 




103 


NC-collision 


B.8.3.3 e) 


Resolution 




104 


NC-recovsry 


B.8.3.3 f) 


Do not, Do 




!C5 


NC-assignment right 


B.8.3.3 g) 


Receiver, Sender, All 





C,1 1 .2 Parameter values for OR TPDU (01 :: OR C2:: OR C3:: OR 04:: or C4L::) 

If the additional options selection parameter is issued in a CR TPDU it is mandatory that 



index 



ICR1 



Bits 8 and 7 shall be set to zero 



If the preferred class in the CR is 2, 3 or 4 



Index 



ICR2 



Is class always offered as an alternative class? 



References^' 



14.4 



Status 



O 
CCT:M 



References 



13.3.4 g) 



Support 



Yes No 
Yes No 
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C.11 .3 Supported parameters foe class TPDUs (CO::) 

The foliowing parameters are optional if a CR TPDU is issued with preferred class 



Index 


Supported parameters 


References 


Status 


Support 


I0CR6 


Called TSAP-ID 


13.3.4 a) 


O 


Yes No 


I0CR7 


Calling TSAP-ID 


13.3.4 a) 





Yes No 


I0CR8 


TPDU size 


13.3.4 b) 


O 


Yes No 


I0CR9 


Preferred maximum TPDU size 


13.3.4 c) 


O 


Yes No 


The followinq parameters are optional if a CC TPDU is issued in class 


Index 


Supported parameters 


References 


Status 


Support 


I0CC6 


Called TSAP-ID 


13.4.4 


O 


Yes No 


I0CC7 


Calling TSAP-ID 


13.4.4 


O 


Yes No 


I0CC8 


TPDU size 


13.4.4 


O 


Yes No 


I0CC9 


Preferred maximum TPDU size 


13.4.4 


O 


Yes No 


The followinq parameter is optional if a DR TPDU is issued in class 


index 


Supported parameter 


References 


Status 


Support 


10DR4 


Additional information 


13.5.4 a) 





Yes No 



C.1 1 .4 Supported parameters for class 1 TPDUs (CI ::) 



Index 


Supported parameters 


References 


Status 


Support 


I1CR6 


Called TSAP-ID 


13.3.4 a) 





Yes No 


I1CR7 


Calling TSAP-ID 


13.3.4 a) 





Yes No 


I1CR8 


TPDU size 


13.3.4 b) 





Yes No 


11CR9 


Version number 


13.3.4 d) 





Yes No 


I1CR10 


Protection parameters 


13.3.4 e) 


O 


Yes No 


I1CR11 


Additional option selection 


13.3.4 g) 


O 


Yes No 


I1CR12 


Alternative protocol class 


13.3.4 h) 





Yes No 


i1CRl3 


Throughput 


13.3.4 k) 





Yes No 


I1CR14 


Residual error rate 


13.3.4 m) 


O 


Yes No 


I1CR15 


Priority 


13.3.4 n) 





Yes No 


I1CR16 


Transit delay 


13.3.4 p) 





Yes No 


11CR17 


Reassignment time 


13.3.4 q) 


O 


Yes No 


I1CR18 


Preferred maximum TPDU size 


13.3.4 c) 


O 


Yes No 
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The following parameters are optional if a CC TPDU is issued in class 1 








Index 


Supported parameters 


References 


Status 


Support 


I1CC6 


Called TSAP-ID 


13.4.4 


O 


Yes No 


I1CC7 


Calling TSAP-ID 


13.4.4 


O 


Yes No 


I1CC8 


TPDU size 


13.4.4 





Yes No 


I1CC9 


Protection parameters 


13.4.4 


O 


Yes No 


I1CC10 


Additional option selection 


13.4.4 


O 


Yes No 


I1CC11 


Throughput 


13.4.4 


O 


Yes No 


I1CC12 


Residual error rate 


13.4.4 


O 


Yes No 


I1CC13 


Priority 


13.4.4 


O 


Yes No 


I1CC14 


Transit delay 


13.4.4 


o 


Yes No 


I1CC15 


Preferred maximum TPDU size 


13.4.4 





Yes No 



The following parameter is optional if a DR TPDU is issued in class 1 








Index 


Supported parameter 


References 


Status 


Support 


I1DR4 


Additional information 


13.5,4 a) 





Yes No 



The following parameter is optional if a ER TPDU is issued in class 1 








r 
index 


Supported parameter 


References 


Status 


Support 


I1ER3 


Invalid TPDU 


13.12.4 a) 


O 


Yes No 



The following parameter is mandatory in a DT TPDU if request of acknowledgement has been selected 




Index 


Supported parameter 




References Status 


Support 


I1DT4 


ROA 


13.7.3 a) M 


Yes No 
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The follov 


ving parameters are optional if a CR TPDU is issued with preferred class 


2 






Index 


Supported parameters 


References 


Status 


Support 


I2CR6 


Called TSAP-ID 


13.3,4 a) 


O 


Yes No 


I2CR7 


Calling TSAP-ID 


13.3.4 a) 


o 


Yes No 


I2CR8 


TPDU size 


13.3.4 b) 


o 


Yes No 


" I2CR9 


Version number 


1 3.3,4 d) 





Yes No 


I2CR10 


Protection parameters 


13.3.4 e) 


o 


Yes No 


I2CR11 


Additional option selection 


13.3.4 g) 


o 


Yes No 


I2CR12 


Alternative protocol class 


13.3.4 h) 


o 


Yes No 


I2CR13 


Throughput 


13.3.4 k) 


o 


Yes No 


I2CR14 


Residual error rate 


13.3.4 m) 





Yes No 


12CR15 


Priority 


13.3.4 n) 


o 


Yes No 


I2CR16 


Transit delay 


13.3.4 p) 


o 


Yes No 


12CR17 


Preferred maximum TPDU size 


13.3.4 c) 


o 


Yes No 



The following parameters are optional if a CC TPDU is issued in class 2 










Index 


Supported parameters 


References 


Status 


Supp 


ort 


I2CC6 


Called TSAP-ID 


13.4.4 


O 


Yes 


No 


I2CC7 


Calling TSAP-ID 


13.4.4 


o 


Yes 


No 


I2CC8 


TPDU size 


13.4.4 





Yes 


No 


12CC9 


Protection parameters 


13.4.4 


o 


Yes 


No 


I2CC10 


Additional option" selection 


13.4.4 


o 


Yes 


No 


I2CC11 


Throughput 


13.4.4 


o 


Yes 


No 


I2CC12 


Residual error rate 


13.4.4 


o 


Yes 


No 


I2CC13 


Priority 


13.4.4 





Yes 


No 


I2CC14 


Transit delay 


13.4.4 


o 


Yes 


No 


I2CC15 


Preferred maximum TPDU size 


13.4.4 





Yes 


No 



The following parameter is optional if a DR TPDU is issued in class 2 








Index 


Supported parameter 


References 


Status 


r-- - - 

Support 


t20R4 


Additional information 


13.5.4 a) 


O 


Yes No 



The following parameter is optional if an ER TPDU is issued in class 2 








Index 


Supported parameter 


References 


Status 


Support 


I2ER3 


Invalid TPDU 


13.12.4 a) 


O 


Yes No 
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C.1 1 .6 Supported parameters for class 3 TPDUs (C3::) 

The follovying parameters are optional if a CR TPDU is issued with preferred class 3 



Index 


Supported parameters 


References 


Status 


Support 


I3CR6 


Called TSAP-ID 


13.3.4 a) 





Yes No 


I3CR7 


Calling TSAP-ID 


13.3.4 a) 


O 


Yes No 


I3CR8 


TPDU size 


13.3.4 b) 


O 


Yes No 


I3CR9 


Version nunnber 


13.3.4 d) 


O 


Yes No 


!3CR10 


Protection parameters 


13.3.4 e) 


O 


Yes No 


I3CR1 1 


Additional option selection 


13.3.4 g) 


o 


Yes No 


I3CR12 


Alternative protocol class 


1 3.3.4 h) 


o 


Yes No 


I3CR13 


Throughput 


13.3.4 k) 


o 


Yes No 


I3CR14 


Residual error rate 


13.3.4 m) 





Yes No 


t3CRl5 


Priority 


13.3.4 n) 


o 


Yes No 


13CR16, 


Transit delay 


13,3.4 p) 


o 


Yes No 


(3CR17 


Reassignment time 


13.3.4 q) 


o 


Yes No 


I3CR18 


Preferred maximum TPDU size 


13.3.4 c) 





Yes No 


The lollow 


ling parameters are optional if a CC TPDU is issued in class 3 








Index 


Supported parameters 


References 


Status 


Support 


I3CC6 


Called TSAP-ID 


13.4.4 


O 


Yes No 


I3CC7 


Calling TSAP-ID 


13.4.4 


O 


Yes No 


13CC8 


TPDU size 


13.4.4 


O 


Yes No 


I3CC9 


- 

Protection parameters 


13.4.4 





Yes No 


I3CC10 


Additional option selection 


13.4.4 


O 


Yes No 


I3CC11 


Throughput 


13.4.4 





Yes No 


I3CC12 


Residual error rate 


13.4.4 





Yes No 


13CC13 


Priority 


13.4.4 





Yes No 


i3CCl4 


Transit delay 


13.4.4 





Yes No 


i3CCl5 


Preferred maximum TPDU size 


13.4.4 





Yes No 


The follov 


vtnq parameter is optional if a DR TPDU is issued in class 3 








index 


Supported parameter 


References 


Status 


Support 


I3DR4 


Additional information 


13.5.4 a) 





Yes No 


The follov 


ving parameter is optional if a ER TPDU is issued in class 3 








Index 


Supported parameter 


References 


Status 


Support 


I3ER3 


Invalid TPDU 


13.12.4 a) 





Yes No 
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The following parameter is mandatory in a DT TPDU if request of acknowledgement has been selected 



Index 



Supported parameter 



References 



Status 



Support 



I3DT4 



ROA 



13.7.3 a) 



M 



Yes No 



C.11.7 Supported parameters for class 4 TPDUs (C4 OR C4L::) 



Index 


Supported parameters 


References 


Status 


Support 


I4CR7 


Called TSAP-ID 


13.3.4 a) 


O 


Yes No 


t4CR8 


Calling TSAP-ID 


13.3.4 a) 


O 


Yes No 


I4CR9 


TPDU size 


13.3.4 b) 


o 


Yes No 


i4CRlO 


Version number 


1 3.3.4 d) 





Yes No 


I4CR1 1 


Protection parameters 


13.3.4 e) 


o 


Yes No 


I4CR12 


Additional option selection 


13.3.4 g) 





Yes No 


I4CR13 


Throughput 


13.3.4 k) 


o 


Yes No 


)4CR14 


Residual error rate 


13.3.4 m) 





Yes No 


I4CR15 


Priority 


13.3.4 n) 


o 


Yes No 


I4CR16 


Transit delay 


13.3.4 p) 





Yes No 


I4CR17 


Acknowledge time 


13.3.4 j) 





Yes No 


I4CR18 


Preferred maximum TPDU size 


13.3.4 c) 


o 


Yes^ No 


I4CR19 


Inactivity time 

- — - — ~ — ■ — ' 


13.3.4 r) 





Yes No 



The following parameters are optional if a CR TPDU is issued with preferred class 4 over CONS 



Index 



I4CR20 



Supported parameter 



Alternative protocol class 



References 



13.3.4 h) 



Status 



O 



Support 



Yes No 
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The follow 


ring parameters are optional if a CC TPDU is issued in class 4 










Index 


Supported parameters 


References 


Status 


Support 




I4CC6 


Called TSAP-ID 


13.4.4 


O 


Yes No 




14CC7 


Calling TSAP-ID 


13.4.4 


O 


Yes No 




I4CC8 


TPDU size 


13.4.4 





Yes No 




14CC9 


Protection parameters 


13.4.4 





Yes No 




I4CC10 


Additional option selection 


. 13.4.4 


O 


Y,es No 




I4CC11 


Acknowledge time 


13.4.4 


O 


Yes No 




I4CC12 


Throughput 


13.4.4 


O 


Yes No 




I4CC13 


Residual error rate 


13.4.4 





Yes No 




I4CC14 


Priority 


13.4.4 


O 


Yes No 




I4CC15 


Transit delay 


13.4.4 


O 


Yes No 




I4CC16 


Preferred maximum TPDU size 


13.4.4 


o 


Yes No 




I4CC17 


Inactivity time 


13.4.4 


o 


Yes No 




The following parameter is optional if a DR TPDU is issued in class 4 










Index 


Supported parameter 


References 


Status 


Support 




14DR4 


Additional information 


13.5.4 a) 


O 


Yes No 




The following parameter is mandatory in a DT TPDU if request of acknowledgeme 


nt has been selected 






Index 


Supported parameter 


References 


Status 


Support 




I4DT4 


ROA 


13.7.3 a) 


M 


Yes No 




The following parameter is mandatory in an AK TPDU if issued in class 4 










Index 


Supported parameter 


References 


Status 


Support 




14AK4 


Flow control confirmation 


13.9.4 c) 


O 


Yes No 




If the implementation can reduce credit and does so in the manner outlined in 
TPDUs is mandatory. Otherwise complete item t4AK5 


12.2.3.8.2 the 


m subsequent 


;e number in i 


^K 


index 


Supported parameter 


References 


Status 


Support 




I4AK5 


Subsequence number 


13.9.4 b) 


O 


Yes No 




The following parameter is optional in an AK TPDU if selective acknowledgement 


has been neg( 


stiated. 






Index 


Supported parameter 


References 


Status 


Support 




14AK6 


Selective acknowledgement parameters 


13.9.4 d) 


O 


Yes No 




The following parameter is optional if an ER TPDU is issued in class 4 


Index 


Supported parameter 


References 


Status 


Support 




I4ER3 


Invalid TPDU 


13.12.4 a) 





Yes No 
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C.1 2 Supported parameters for received TPDUs 

Implementors should be aware that implementations shall be capable of receiving and processing all possible paranneters for all 
possible TPDUs, dependent upon the class and optional functions implemented. 

C.1 2.1 Supported parameters for NCMS (A1 ::) 

C.I 2.1. 2 NCM TPDU (SN4::) 



Index 


Supporled parameters 


References 


Allowed values 


Supported values 


RN1 


NC-type 


B.8.3.3 c) 


New, My, Yours 




RN2 


NC-preference 


B.8.3.3 d) 


Highest, Medium, Lowest 




RN3 


NC-collision 


B.8.3.3 e) 


Resolution 




RN4 


NC-recovery 


B.8.3.3 f) 


Do not. Do 




RN5 


NC-assignment right 


B.8.3.3 g) 


Receiver, Sender, All 





C.1 2.2 TPDUs in class 4 (C4 OR C4L::) 

If use of checksum has been selected then it is mandatory to process a checksum parameter in the toUowtng TPDUs 



Index 


TPDUs 


References 


Status 


Support 


R4CCch 


CCTPDU 


13.4.4 


M 


Yes 


R4DRch 


DRTPDU 


13.5.4 b) 


M 


Yes 


R4DCch 


DC TPDU 


13.6.4 


M 


Yes 


R4DTch 


DTTPDU 


13.7.4 


M 


Yes 


R4EDch 


ED TPDU 


13.8.4 


M 


Yes 


R4AKch 


AKTPDU 


13.9.4 a) 


M 


Yes 


R4EAch 


EATPDU 


13.10.4 


M 


Yes 


R4ERch 


ERTPDU 


13.12.4 b) 


M 


Yes 



121 



IS 13919: 1994 
ISO/IEC 8073 : 1992 



C.1 3 User data in issued TPDUs 



A TS-user may issue data with a T-CONNECT request, T-CONNECT response or T-DISCONNECT request. Then it shall be 
possible to send user data as follows: 

C.I 3.1 Class 1(C1::) 



Index 


User data 


References 


Status 


Support 


DliCR 


User data of up to 32 octets in a CR with preferred class 1 


13.3.5 


M 


Yes 


D1ICC 


User data of up to 32 octets in a CC 


13.4.5 


M 


Yes 


D1IDR 


User data of up to 64 octets in a DR 


13.5.5 


M 


Yes 



C.1 3.2 Class 2 (C2::) 



index ■ 


User data 


References 


Status 


Support 


D2iCR 


User data of up to 32 octets in a CR with preferred class 2 


13.3.5 


M 


Yes 


D2ICC 


User data of up to 32 octets in a CC 


13.4.5 


M 


Yes 


D2IDR 


User data of up to 64 octets in a DR 


13.5.5 


M 


Yes 



C.1 3.3 Class 3 (C3::) 



Index 


User data 


References 


Status 


Support 


D31CR 


User data of up to 32 octets in a CR with preferred class 3 


13.3.5 


M 


Yes 


D31CC 


User data of up to 32 octets in a CC 


13.4.5 


M 


Yes 


D3IDR 


User data of up to 64 octets in a DR 


13.5.5 


M 


Yes 



C.13.4 Class4(C4orC4L::) 



Index 


User data 


References 


Status 


Support 


D4tCR J 


User data of up to 32 octets in a CR with preferred class 4 


13.3.5 


M 


Yes 


D4ICC 


User data of up to 32 octets in a CC 


13.4.5 


M 


Yes 


D4IDR 


User data of up to 64 octets in a DR 


13.5.5 


M 


Yes 
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C.14 User data in received TPDUs 

For classes 1 to 4. if it is possible to initiate a CR TPDU then it shall be possible to receive the following. 



index 



DRCC 



DRDR 



User data 



32 octets of user data in a CC TPDU 



64 octets of user data in a DR TPDU 



References 



13.4.5 



13.5.5 



For classes 1 to 4, if it is possible to respond to a CR TPDU then it shall be possible to receive the following. 



Index 



DRCR 



User data 



32 octets of user data in a CR TPDU 



References 



13.3.5 



C.I 5 Negotiation 

C.15.1 Class negotiation - initiator 

If it is possible to initiate a CR TPDU in a particular class then the following holds. 



Index 



NC 



The preferred class in the CR TPDU may contain any of the classes supported by the 
implementation 



References 



6.5.4 h) 



What classfes] 


is (are) contained in the alternative class parameter if the preferred class is: 




Index 


Preferred class 


References 


Allowed values 


Supported values 


NAC1 


Class 1 


6.5.4 h) 


None, 0, 1 




NAC2 


Class 2 


6.5.4 h) 


None, 0, 2 




NAC3 


Class 3 


6.5.4 h) 


None, 0, 1, 2, 3 




NAC4 


Class 4 over CONS 


6.5.4 h) 


None, 0, 1,2, 3, 4 




NAC5 


Class 4 over CLNS 


6.5.5 h) 


None 
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C.I 5.2 Class negotiation - responder 



Index 


Preferred class 


References 


Allowed response 


Supported response 


RCO 


What classes can you respond with if CR 
proposes only class 0? 


6.5.4 h) 
Table 3 


or connection refused 
depending on classes 
supported 




RC1 


What classes can you respond with if CR 
proposes only class 1? 


6.5.4 h) 
Table 3 


0, 1 or connection 
refused depending on 
classes supported 




RCia 


What classes can you respond with if CR 
proposes class 1 as preferred class and the 
alternative class parameter is present? 


6.5.4 h) 
Table 3 


0, 1 or connection 
refused depending on 
classes supported 




RC2 


What classes can you respond with if CR 
proposes only class 2? 


6.5.4 h) 
Table 3 


2 or connection refused 
depending on classes 
supported 




RC2a 


What classes can you respond with if CR 
proposes class 2 as preferred class and the 
alternative class parameter is present? 


6.5.4 h) 
Table 3 


0, 2 or connection 
refused depending on 
classes supported and 
coding of alternative 
class 




RC3 


What classes can you respond with if CR 
proposes only class 3? 


6.5.4 h) 
Table 3 


2,3 or connection 
refused depending on 
classes supported 




RC3a 


What classes can you respond with if CR 
proposes class 3 as preferred class and the 
alternative class parameter is present? 


6.5.4 h) 
Table 3 


0, 1, 2, 3 or connection 
refused depending on 
classes supported and 
coding of alternative 
class 




RC4 


What classes can you respond with if CR 
proposes only class 4? 


6.5.4 h) 
Table 3 


2, 4 or connection 
refused depending on 
classes supported 




RC4a 


What classes can you respond with if CR 
proposes class 4 as preferred class and the 
alternative class parameter is present? 


6.5.4 h) 
Table 3 


0, 1,2, 3, 4 or 
connection refused 
depending on classes 
supported and coding of 
alternative class 





C.I 5.3 TPDU size negotiation 



Index 



TS1 



TS2 



If maximum TPDU size is proposed in a CR TPDU then the initiator 
shall support all TPDU sizes from 128 octets to the maximum 
proposed. 



If the preferred maximum TPDU size parameter is used in a CR TPDU 
then the initiator shall support all TPDU sizes, except 0, that are 
multiples of 128 octets up to the preferred maximum proposed. 



References 



14.6 



14.6 e) 



Status 



M 



I4CR18:M 



Support 



Yes 



Yes No 
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Index 


TPDU size 


References 


Allowed values 


Supported values 


T0S1 


What is the largest value of the maximum TPDU 
size parameter in a CR TPDU with preferred 
clasc 0? 


14.6e) 


NOTI0CR9:Oneof 128, 
256, 512, 1024,2048 
I0CR9: One of nx128 with 
n= 1,2,3,... 




T0S2 


What is the largest value of the maximum TPDU 
size parameter which may be sent in a CC 
TPDU when class is selected? 


14.6e) 


NCTI0CC9:Oneof 128, 
256, 512, 1024, 2048 
I0CC9: One of nx128 with 
n = 1,2,3,... 




T1S1 


What is the largest value of the maximum TPDU 
size parameter in a CR TPDU with preferred 
class 1? 


14.6 e) 


NOTIlCRl8:Oneof 128, 

256,512. 1024, 2048, 

4096,8192 

I1CR18: One of nx128 

with n= 1, 2, 3, ... 




T1S2 


What is the largest value of the maximum TPDU 
size parameter which may be sent in a CC 
TPDU when class 1 is selected? 


14.6 e) 


NOT I1CC15: One of 128, 
256. 512, 1024, 2048. 
4096, 8192 
l1CC15:Oneof nx128 
with n = 1, 2, 3, ... 




T2S1 


What is the largest value of the maximum TPDU 
size parameter in a CR TPDU with preferred 
class 2? 


14.6 e) 


NOT t2CRl7: One of 128, 
256,512, 1024,2048, 
4096,8192 

l2CRl7:Oneof nx12a 
with n = 1, 2, 3, ... 




T2S2 


What is the largest value of the maximum TPDU 
size parameter which may be sent in a CC 
TPDU when class 2 is selected? 


14.6e) 


NOTl2CCl5:Oneof 128, 

256, 512, 1024, 2048. 

4096,8192 

I2CC15: One of nx128 

with n= 1, 2, 3, ... 




T3S1 


What is the largest value of the maximum TPDU 
size parameter in a CR TPDU with preferred 
class 3? 


14.6 e) 


NOTi3CRl8: One of 128. 
256, 512, 1024, 2048. 
4096,8192 

l3CR18:Oneof nx128 
with n:= 1, 2, 3, ... 




T3S2 

i 


What is the largest value of the maximum TPDU 
size parameter which may be sent in a CC 
TPDU when class 3 is selected? 


14.6e) 


NOTI3CCl5:Oneof 128, 
256, 512, 1024, 2048. 
4096, 8192 

l3CC15:Oneof nx128 
with ni= 1, 2, 3, ... 


1 

i 


T4S1 


What is the largest value of the maximum TPDU 
size parameter in a CR TPDU with preferred 
class 4? 


14.6e) 


NOTI4CR-:8: One of 128, 
256, 512, 1024, 2048, 
4096,8192 

I4CR18: One of nx128 
with r, i^ 1, 2, 3, .. i 


j 
1 


T4S2 


What is the largest value of the maximum TPDU 
size parameter which may be sent in a CC 
TPDU when class 4 is selected? 


14.6 e) 


NOT i4Cr;l6. One of )28, 
256 512, 1C24, 2048. 
4096. 8192 

i4CC16: One o* nx128 
with n :^ 1, 2, 3, ... 
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C.I 5.4 Use of extended format 



Index 


Extended format 


References 


Allowed 
values 


Supported 
values 


NEF1 


What fCi mats can you propose in the CR TPDU in class 2? 


6.5.4 n) 


normal, 
extended 




NEF2 


What formats can you propose in the CR TPDU in class 3? 


6.5.4 n) 


normal, 
extended 




NEF3 


What formats can you propose in the CR TPDU in class 4? 


6.5.4 n) 

6.5.5 n) 


normal, 
extended 




NEF4 


Vv'hat formats can you select in CC when extended has been 
proposed in CR in class 2? 


6.5.4 n) 


normal, 
extended 




NEF5 


What formats can you select in CC when extended has been 
proposed in CR in class 3? 


6.5.4 n) 


normal, 
extended 




NEF6 


What formats can you select in CC when extended has been 
proposed in CR in class 4? 


6.5.4 n) 

6.5.5 n) 


normal, 
extended 





C.15.5 Expedited data transport service 



1 
Index 


References 


Status 


Support 


TED1 Expedited data indication in CR and CC TPDU 


6.5.4 1) 
6.5.5 r) 


M 


Yes 



C.1 5.6 Non-use of checksum {(04 OR C4L) AND T4F29::) 



Index 


Non-use of checksum 


References 


Allowed 
values 


Supported 
values 


NUCi 


What proposals can you make in the CR? 


6.5.4 p) 

6.5.5 p) 


non-use, 
use 




NUC2 What proposals can you make in CC when non-use of checksum has 
1 been proposed in CR? 


6.5.4 p) 

6.5.5 p) 


non-use, 
use 





0.1 5.7 Explic it flow control (02 and T2F1 9::) 



Index 


Explicit flow control 


References 


Allowed 
values 


Supported 
values 


NUF1 


What proposals can you make in the CR? 


6.5.4 r) 


non-use, 
use 




NUF2 


What proposals can you make in CC whan non-use of explicit flow 
control has been proposed in CR? 


6.5.4 r) 


non-use, 
use ^ 
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C.I 5.8 Use of network receipt confirmation (CI and T1 F21 ::) 



Index 


Network receipt confirmation 


References 


— 1 
Allowed 
values 


Supported 
values 


UNRC1 


What proposals can you make in the CR? 


6.5.4 s) 


non-use, 
use 




UNRC2 


What proposals can you make in CC when use of network receipt 
confirmation has been proposed in CR? 


6.5.4 s) 


non-use, 
use 





0.1 5.9 Use of network expedited data (CI and T1F20::) 



Index 


Network expedited data 


References 


Allowed 
values 


Supported 
values 


UNED1 


What proposals can you make in the CR? 


6.5.4 s) 


non-use, 
use 




UNED2 


What proposals can you make in CC when use of network expedited 
data has been proposed in CR? 


6.5.4 s) 


non-use, 
use 





C.15.10 



Use of selective acknowledgement 



Index 


Selective acknowledgement 


References 


Allowed 
values 


Supported 
values 


USA1 


Is use of selective acknowledgement proposed in CR TPDUs? 


6.5.4 u) 

6.5.5 s) 


Yes, No 




USA2 


Is use of selective acknowledgement selected in a CC when it has 
been proposed in a CR? 


6.5.4 u) 

6.5.5 s) 


Yes, No 





C.15.11 



Use of request of acknowledgement 



Index 


Request of acknowledgement 


References 


Allowed Supported 
values values 


ROA1 


Is use of request of acknowledgement proposed in CR TPDUs? 


6.5.4 V) 

6.5.5 t) 


Yes, No 




ROA2 


Is use of request of acknowledgement selected in a CC when it has 
been proposed in a CR? 


6.5.4 V) 

6.5.5 t) 


Yes, No 
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C.16 Error handling 

C.I 6.1 Action on receipt of a protocol error 



Index 


Item 


References 


Allowed values 


Supported values 


PEO 


Class 


6.22.1.3 


CO: ER, NDISreq, 
NRSTreq, Discard 




PE1 


Class 1 


6.22.1.3 


CI; ER, DR, NDISreq, 
NRSTreq, Discard 




PE2 


Class 2 


6.22.1.3 


C2: ER, DR, NDISreq, 
NRSTreq, Discard 




Pfc3 


Class 3 


6.22.1.3 


C3: ER, DR, NDISreq, 
NRSTreq, Discard 




PE4 


Class 4 over CONS 


6,22.1.3 


C4: ER, DR, NDISreq, 
NRSTreq, Discard 




PE4L 


Class 4 over CLNS 


6.22.2.3 


C4L; ER, DR, Discard 





0.1 6.2 Actions on recelnt of an invaiid or undefined oarameter in a OR TPDU 



Index Event References 


Status 


Support 


RR1 j .A psra.-rseier not defined in ISO 8073 shall be ignored 


13.2.3 


fvl 


Yes 


RR2 
RR3 


An i.nvatid value in tine alternative protocol class parameter shall be 
treated as a protocol error 


13.2.3 


M 


Yes 


.An invaiid value in the class and option parameter shall be treated as 
a protocol error 


13.2.3 


M 


Yes 


nR4 


On receipt of th.e additional option selection parameter bits 8 to 5, and 
bits 4 to 1 if not meaningful for the proposed class shall be ignored. 


13.3.4 


M 


Yes 


RRS 


... 

If non-use of explicit fiow control is proposed and bit 1 of the additional 
option selection parameter equals 1 , it shall be treated as a protocol 
error. 


13.2.3 


M 


Yes 


RR6 


On receipt of the class and option parameter bits 4 to 1 if not 
meaningful for the proposed class shall be ignored 


13.3.3 


M 


Yes 

I 



What actiori is supported on receipt of the following? 








Index 


Event 


References 


Allowed 
actions 


Supported 
actions 


RR7 


A parameter defined in ISO/IEC 8073 (other than those covered 
above) and have an invalid value 

■ 


13.2.3 


Ignore, 

pro toco! 

error 


_ 
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C.I 6.3 Actions on receipt of an invalid or undefined parameter in a TPDU other than a CR TPDU 

The following ac tions are man datory 



Index 


Event 




References 


Status 


Support 


UI1 


A parameter not defined in iSO/lEC 8073 shall be treated as a 
protocol error 


13.2.3 


M 


Yes 


UI2 


A parameter which has an invalid value as defined in iSO/lEC 8073 
shall be treated as a protocol error 


13.2.3 


M 


Yes 


UI3 

(class 4 

only) 


A TPDU received with a checksum which does not satisfy the defined 
formula shall be discarded. 


6.17.3 


M 


Yes 



C.I 7 Timers and protocol parameters 

The following are mandatory if class 4 is supported. 



Index 




References 


Status 


Support 


TA1 


Tf 


12.2.1 


M 


Yes 


TA2 


N 


12.2.1 


M 


Yes 


TA3 


k 


12.2.1 


M 


Yes 


TA4 


W 


12.2.1 


M 


Yes 


TAB 


L 


12.2,1 


M 


Yes 



Index 




References 


Status 


Supp 


ort 


0T1 


Does lUT support optional timer TS1 when operating in class 0? 


6.5.4 


O 


Yes 


No 


0T2 


Does lUT support optional timer 757 when operating in class l? 


6.5.4 


o 


Yes 


No 

1 
No 


0T3 


Does lUT support optional timer 757 when operating in class 2? 


6.5.4 


o 


Yes 


0T4 


Does lUT support optional timer 7S7 when operating in class 3? 


6.5.4 


o 


Yes 


No 


0T5 


Does lUT support optional timer 7S2 when operating in class 0? 


6.7.1.5 


o 


Yes 


No 


0T6 


Does lUT support optional timer 7S2when operating in class 1? 


6.7.1.5 


o 


Yes 


No 


0T7 


Does lUT support optional timer 7S2when operating in class 2? 


6.7.1.5 


o 


Yes 


No 


0T8 


Does lUT support optional timer 7S2when operating in class 3? 


6.7.1.5 


o 


Yes 


No 


OT9 


Does lUT support optional timer 7Si>when operating in class 4? 


6.22.1.3 
6.22.2.3 


o 


Yes 


No 



The (ollowinq are mandatory if class 1 or 3 is supported. 








Index 




References 


Status 


Support 


TA6 


TTR 


6.12.3 
6.12.4 


M 


Yes 

Yes 

1 
* 1 


TA7 


TWR 


6.12.3 
6.12.4 


M 
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Annex D 

(informative) 

Checksum Algorithms 



D.I Symbols 

The following symbols are used 

CO, CI variables used in the algorithms 

/ is the number (i.e. position) of an octet within the 
TPDU(see 12.1); 

n is the number (i.e. position) of the first octet of the 
checksum parameter; 

L is the length of the complete TPDU; 

X is the value of the first octet of the checksum 
parameter; 

Y is the value of the second octet of the checksum 
parameter. 

D.2 Arithmetic conventions 

Addition is performed in one of the two following modes: 

a) modulo 255 arithmetic; 

b) ones complement arithmetic in which if any of the 
variables has the value minus zero (i.e. 255) it shall be 
regarded as though it was plus zero (i.e. 0). 

D.3 Algorithm for generating checksum 
parameters 

D.3.1 Set up the complete TPDU with the value of the 
checksum parameter field set to zero. 

D.3.2 Initialize CO and 01 to zero. 

D.3.3 Process each octet sequentially from /= 1\o Lby 

a) adding the value of the octet to CO; then 



b) adding the value of CO to CI. 

D.3.4 Calculate X and Y such that 

X=-C1 + (L-n) CO 

Y=C1-{L-n-i- r) CO 

D.3.5 Place the values X and Y in octets n and {n + 1) 
respectively. 

NOTE - This algorithm calculates 



C1=J, iL-i+ 7) a, 



which is equal to zero, if the formulae in 6.17.3 are followed, since 

L i L 

Y{L-i+1)ar{L+ 7) y a;- y /a,= 
(= ( 1=1 /= 1 



D.4 Algorithm for checking checksum 
parameters 

D.4.1 Initialize CO and CI to zero. 

D.4.2 Process each octet of the TPDU sequentially 
from /= 7 to L by 

a) adding the value of the octet to CO. then 

b) adding the value of CO to CI. 

D.4.3 If, when all the octets have been processed, one or 
both of the parameters CO and C1 do not have the value 
zero, the checksum formulae in 6.17 have not been 
satisfied. 

NOTE - The nature of the algorithm is such that it is not necessary 
to compare explicitly the stored checksum bytes. 
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Annex E 

(Informative) 

State tables for operation of class 4 over connection-mode and 
connectionless-mode network services 



E.1 General 

This annex has been included as a guide for 
impiennentations which have been designed for operation 
over both the connection-mode network service and the 
connectioniess-mode network service. 

The introductory comments given in annex A apply in this 
annex as well. 



E,2 Conventions 

Clause A,2 applies in this annex, except for item b) of A.2.3, 
in which the term "network connection" is to be extended to 
apply as well to the corresponding instance of 
communication over a connectionless-mode network 

service. 



E.3 Tables 

Clause A.3, including tables A.I, A.2, A.3, apply in this 
annex. 



a)* the state of every network connection is known as 
being open or opening (i.e. a NCONreq has been issued 
and the NCONconf is awaited); 

b)* for each transport connection the transport entity 
maintains the set of network connections to which the 
transport connection is assigned. A network connection 
in this set is either in the open or opening states; 

c)* when a N-GONNECT confirmation, N-RESET 
indication or N-DISCONNECT indication is received this 
event is associated with the transport connection if the 
network connection belongs to the set; 

d)* when an N-DISCONNECT is received, the network 
connection ceases to exist and is therefore withdrawn 
from the set. When a NCONcon* is received the state of 
the NC becomes "open"; 

NOTE - This is not shown by an explicit action in the state 
table. Conversely adding a network connection to a set and 
setting its state to "opening" is shown by an explicit action. 

e)* when the state goes back to CLOSED or 
REFWAIT state, it is assumed that all timers are stopped 
{if running), the count is set to zero and the set becomes 
empty; 



E.4 State tables for Class 4 

This clause incorporates all of clause A.6 with extensions to 
cover operation over connectionless-mode network 
services. 

This clause provides a more precise description of a class 4 
transport connection. 

Tables E.I, E.2, E.3 give the predicates, actions and notes 
for class 4 respectively. 

Table E.4 is the state table for a class 4 transport 
connection. 

The following assumption and notations are used: 

* : appropriate only for operation over connection-mode 
network service 

** : appropriate only for operation over connectionless-mode 
network service 



f)* when a PDU is received the network connection on 
which it has been received is assumed to be known; 

g)* the variable "current-NC" is used to designate 
either the network connection on which a TPDU has 
been received or the network connection which has 
been choosen for a new assignment (either an existing 
one or a new one which is created); 

h) we also assume the following variables: 

local-ref: the reference (local) of the TC is chosen 
when sending the CR or when accepting a CR; 

remote-ref; the reference of the remote entity is 
initially set to zero and initialised when processing 
the CC except if the CC is ignored. 

SRC-REF: designates the corresponding field of the 
received TPDU. 

DST-REF: designates the corresponding field of the 
received TPDU. 

src-ref, dst-ref: designates the corresponding fields 
of the sent TPDU. 

count: designates the numbers of times a T'PDU has 
been sent (retransmissions); 



131 



IS 13919: 1994 

I SO/I EC 8073 : 1992 



i) the data transfer phase is not completely described 
in the state table but refers to the main text; 

j)* a spontaneous event called "new network 
connection assignment" has been introduced. It may 
occur at any time provided PI or P2 are true (see 
predicate table E.I) and the remote-ref is not zero (i.e. a 
CR TPDU has been received or a CC TPDU has been 
received and processed); 



k)' when a N-RESET indication is received, an N- 
RESET response is issued; 

I)** it is assumed that the connectionless-mode 
network service when being used is continuously 
available. The operations resulting from signalled 
inaccessibility of the network are a local matter. 



Table E.I - Predicates for class 4 



Name 


Description 


PO 


T-CONNECT request is acceptable. 


PI 


An assignment can be done to a suitable network connection {either open or 
opening). 


P2 


it is possible to open a new network connection. 


P3 


Local choice. 


P4 


A CR TPDU has never been sent. 


P5 


The transport entity is the initiator and the set of network connections is now 
empty (i.e. a new assignment shall be done) or a new assignment is decided 
as a local choice. 


P6 


Local choice not to perform a new assignment if the set of network connections 
is empty (for closing state only). 


P7 


Count = maximum. 


P8 


Acceptable CR TPDU. 


P9 


Acceptable class 4 CC TPDU. 


P10 


Unacceptable class 4 CC TPDU, 


P11 


CC TPDU not specifying class 4. 


P99 


Connection-mode network service being used. 



NOTE - It is assumed that P99 = false implies only that the connectonless-mode network service is 
being used. 
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Table E.2 - Specific actions for class 4 



Name 


Description 


[01 


Set reference timer 


m 


Count = count + 1 


[21 


Count = 


[31 


Set retransmission timer 


[41 


Stop retransmission timer if running 


[51 


Set window timer 


[6] 


Stop window timer if running 


[7] 


Set inactivity timer 


[81 


Stop inactivity timer if running 


[9] 


Set initial credit for sending according to the received CR/CC TPDU 


[10] 


Set initial credit for controtling reception according to the sent CR/CC TPDU 


[11] 


P99: Send the CR TPDU if there is a network connection in the open state in 
the set; not P99: send a CR TPDU 


[12] 


P99: Add the current network connection to the set, if not already included; not 
P99: no action 


[13] 


P99: The current network connection is now in the opening state; not P99: no 
action 


[14] 


P99: Send the CO TPDU if a network connection in the open state is in the set; 
not P99: send CC TPDU 


[15] 


P99: Send the DR TPDU if a network connection in the open state is in the set; 
not P99: send DR TPDU. !n both cases, this DR TPDU is sent with src-ref = 
locgi-ref and dst-ref = remote-ref (may be zero) 


[16] 


P99: Send the DR TPDU if a network connection in the open state is in the set; 
not P99: send the DR TPDU. In both cases, the DR TPDU is sent with src-ref 
= and dst-ref = remote-ref 


[17] 


Send a TPDU according to data transfer procedure 


f18] 


See state table of the class specified in the CC TPDU (refer to data transfer) 


[19] 


P99: See state table of the class (refer to release procedure) send a DR TPDU i 
if the class is not 0, otherwise issue a N-DISCONNECT request; not P99: send 
aDRTPDU 


[20] 


Store request and exercise flow control to the user 


[211 


Send a DR TPDU with src-ref field set to zero 


[22] 


Send a DC TPDU except if the SRC-REF field of the received DR TPDU is 
equal to zero ' 


[23] 


P99: Send a DR TPDU with src-ref = local-ref and dst-ref = remote-ref (may be 
zero) if a network connection in the open state is in the set; not P99: send a DR 
TPDU with src-ref = local-ref and dst-ref = SRC-REF in CC TPDU 
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Table E.3 - Specific notes for class 4 

(* appropriate only when operating over connection-mode network service) 



Name 



Description 



or 



Not possible as no set of network connections is associated with this transport 
connection. 



(2)* 



It is also possible to remain in the same state (T1 is still running) until: 

• a CC TPDU is received which performs a new assignment, 

• a new assignment is tried (spontanous event), 

• T1 runs out and the count is equal to the maximal value. 



(3)* 



No new assignment was possible: if the set is empty, the transport entity waits 
until a new assignment is received, or can be locally performed (spontaneous 
event). 



(4)* 



It is also possible to perform a new assignment. (This may be done in 
triggering the event "new network connection assignment"). 



M. 



Not a duplicated CR TPDU. 



(6)* 



Since a new network connection is now assigned, it is recommended that the 
appropriate TPDU be sent on this network connection (if open) in order to 
make the remote entity aware of this assignment. It is also possible to allow 
the normal retransmission procedures to cause the TPDU to be sent; however 
the first TPDU available for sending should be sent on the new network 
connection. 



(7) 



As a local choice it is also possible to apply the following: [0], TDISind, 
REFWAIT. 



(8) 



Association to this transport connection is done regardless of the SRC-REF 
field. If SRC-REF is not zero, a DC TPDU is set back. 



(9) 



At least an AK TPDU shall be sent if the transport entity is the initiator in order 
to ensure that the responder will complete its three-way handshake. 



(10) 



If association has been made, and DST-REF is zero, then the DC TPDU 
contains a src-ref field set to zero. 



(11) 



If the CLOSING state has been entered, coming from WFCC state, the remote- 
ref is zero. The SRC-REF field of the CC TPDU is ignored (i.e. if the DR TPDU 
is retransmitted, it will be with the dst-ref field set to zero). 



(12)* 



If the CLOSING state has been entered, coming from WFCC state, the remote- 
ref (which is zero) shall be set with SRC-REF in order to comply with the 
release procedure of the negotiated class. 



i13L 



The DR TPDU may be either repeated immediately or when Tl will run out. 



(14)* 



If the set is empty, this event may be used as a criteria for triggering the event 
'^new network connection assignment" 



(15) 



Previously stored T-DATA or T-EXPEDITED-DATA requests are ready for 
processing according to data transfer procedures. 



(16) 



See data transfer procedures. 



(17)* 



When an N-RESET indication is received, an N-RESET response has to be 
issued at once independent of the state automata. 
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Table E.4 - Class 4 connection/disconnection (1 of 2) 



STATE 
EVENT 


■ REFWAIT 


CLOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


TCONreq 




not PO: 
TDISind 
CLOSED; 
PO and {(PI 
and P99) or 
not P99): 
[12,1.3,10,11] 
WFCC; 
P99 and PO 
and not PI 
and P2: 
[13,12,1,3,10] 
NCONreq 
WFCC; 
P99 and PO 
and (not Pi) 
and not P2: 
TDISind 
CLOSED 














TCONresp 












[3,2,1,10,14] 
AKWAIT 






TDiSreq 






P4: 

CLOSED; 
(not P4) 
and P3: 
WBCL; 
(not P4) 
and (not 
P3): 

[4,3,2,1,15] 
CLOSING 




[6,8,4,3,2.1 

.15] 

CLOSING 


[16] 
CLOSED 


[4.3.2,1,15] 
CLOSING 




NDISind 


(1) 


0) 


P99and 


P99 and 


P99 and 


P99: 


P99 and PS 


P99 and PS: 








Pi: 


P3: 


PSand PI: 


WFTRESP 


and Pi: 


[0] 








[12] 


10] 


[12.17] (6) 


(4) 


[12,14] (6) 


REFWEAIT; 








WFCC; 


REFWAIT; 


OPEN; 




AKWAIT; 


P99 and 








P99 and 


P99 and 


P99 and 




P99 and 


(not P6) and 








(not Pi) 


(not P3) 


(not Pi) 




(not PI) 


PSand Pi: 








and P2: 


and Pi: 


andP5 




and P5 and 


[12,15] 








[13,12] 


[12,11] 


and P2: 




P2: 


CLOSING 








NCONreq 


WBCL; 


[13,12] 




[13,12] 


(6) 








WFCC; 


P99 and 


NCONreq 




NCONreq 


P99 and 








P99 and 


(not P3) 


OPEN; 




AKWAIT; 


(not P6) and 








(not Pi) 


and (not 


P99 and 




P99 and 


PS and (not 








and (not 


Pi) and 


(not PI) 




(not PI) 


Pl)andP2: 








P2): 


P2: 


and P5 and 




and P5 and 


[13.12] 








[0] [2] 


[13,12] 


(not P2): 




(not P2): 


NCONreq 








TDISind 


NCONreq 


OPEN (3); 




AKWAIT (3) 


CLOSING; 








REFWAIT 


WBCL; 
P99and 
(not P3) 
and (not 
Pi) and 
(not P2): 
[0] 
REFWAIT 


P99 and 
(not P5): 
OPEN 




P99and 
(not P5): 
AKWAIT 


P99 and 
(not P6) and 
P5 and (not 
PI) and (not 
P2): 

CLOSING 
(3); 

P99and 
(not P6) and 


NRSTind 






/17^ 


/I 7\ 








(not P5): 
CLOSING 


TDTreq 
TEXreq 






tl/J 


(17) 


(17) 
(16) 
OPEN 


(17) 


(17) 
[20] 
AKWAIT 


(17) 
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Table E.5 - Class 4 connection/disconnection (2 of 2) 






STATE 


REFWAIT 


CLOSED 


WFCC 


WBCL 


OPEN 


WFTRESP 


AKWAIT 


CLOSING 


EVENT 


















NCONconf 


(1) 


(1) 


P99: 


P99: 


P99: 


P99: 


P99: 


P99: 








CR 


CR 


[17] 


WFTRESP 


CC 


[15] 








WFCC (6) 


WBCL (6) 


OPEN (6) 




AKWAIT (6) 


CLOSING 
(6) 


Ndw 










P99andP1: 


P99andPV. 


P99andP1: 


P99andP1: 


Network 










[12,17] 


[12] 


[12,14] (6) 


[12,15] (6) 


Connection 










OPEN (6); 


WFTRESP; 


AKWAIT; 


CLOSING; 


Assignment 










P99 and P2 
and (not PI): 
[13,12] 
NCONreq 
OPEN 


P99 and P2 
and (not PI): 
[13, 12] 
NCONreq 
WFTRESP 


P99 and P2 
and (not PI): 
[13,12] 
NCONreq 
AKWAIT 


P99 and P2 
and (not P1): 
[13,12] 
NCONreq 
CLOSING 


Retrans- 






P7andP3: 


P7and 


P7: 




P7: 


97: 


timer 






[0] TDISind 


P3: 


[6,8,3,2,1,15] 




[3.2,1,15] 


[0] 








REFWAIT; 


[0] 


TDISind 




TDISind (14) 


REFWAIT; 








P7 and (not 


REFWAIT; 


CLOSING 




CLOSING; 


not P7: 








P3): 


P7and 


(U); 




not P7: 


[1,3,15] (14) 








[3,2,1,15] 


(not P3): 


not P7: 




[1,3.14] (14) 


CLOSING 








TDISind 


[3.2,1,15] 


(16) (14) 




AKWAIT 










CLOSING 


CLOSING 


OPEN 














(14); 


(14); 








■" 








not P7: 


not P7: 
















[1.3,11] 


[1.3,11] 
















WFCC 


WBCL 










Inactivity- 










[6,4,3,2,1,15] 








Timer 










TDISind 
CLOSING (7) 








Reference- 


CLOSED 
















Time 


















CR 




not P8: 






[12,8,7] 


[12] 


[12,14] 


[12] 






[21] 






OPEN 


WFTRESP 


AKWAIT 


CLOSING 






CLOSED 












(13) 






(5); 


















P8: 


















[9,12] 


















TCONind 


















WFTRESP 
(5) 














CC 


DR 


DR 


P9: 


P99 and 


[12,17,8,7] 






(P99 and 




REFWAIT 


CLOSED 


[12,9,2,4,5, 
7,17] 

TCONconf 
(9) OPEN; 
(not P9 and 
not P99) or 
(P99 and 
P10): 

[12,4,3,2.1,23 
] TDISind 
CLOSING; 
P99andPl1: 
[18] 


P11: 
[19]; 
(not P99 
and P9) or 
(P99 and 
not P1 1): 
[12,2.4,3, 
1,15] 
CLOSING 


(9) OPEN 






P11): 
[19] (12); 
(not P99 and 
P9) or (P99 
and not 
P11): 
[12] 

CLOSING 
(11) 


ER 


REFWAIT 


CLOSED 


[0] TDISind 
REFWAIT 


[0] 
REFWAIT 


[12,6,8,4,3,2, 
1,15] TDISind 
CLOSING 




[12,4,3.2,1, 
15] TDISind 
CLOSING 


[0] REFWAIT 


DR 


[22] 


[22] 


(8) TDISind 


(8) [0] 


DC(10)[0] 


DC (10) 


DC(10)[0] 


[0] REFWAIT 




REFWAIT 


CLOSED 


[0] REFWAIT 


REFWAIT 


TDISind 
REFWAIT 


TDISind 
CLOSED 


TDISind 
REFWAIT 




DC 


REFWAIT 


CLOSED 












[01 REFWAIT 


EA 


REFWAIT 


CLOSED 






[12,8,7] 
OPEN (16) 




« 


[12] CLOSING 
(13) 


DT/AK/ED 

i 


REFWAIT 


CLOSED 






[12,8,7] 
OPEN (16) 




[12,7] OPEN 
(15) (16) 


[12] CLOSING 
(13) 
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